Free UI pattern finder · Web interfaces only
Describe the UI element you see, how it looks or behaves, or what your coding agent got wrong. Compare likely web UI patterns and leave with a testable implementation brief.
01 · Describe an unknown component
Try a field report
03 · 8 ambiguity clusters
Each comparison starts with decisions that change focus, keyboard behavior, modality, persistence, placement, or value handling.
From visual clue to behavior contract
A component name is useful only when it leads to the correct interaction, focus, keyboard, dismissal, and mobile behavior.
Start with what opens the interface, where it appears, whether the page behind it remains usable, what content it contains, and how it closes. You do not need to know the component name. A concrete behavior such as “a card opens on focus and contains a link” is more useful than a visual label such as “small popup.”
The diagnostic keeps two or three plausible candidates instead of pretending the first keyword match is correct. It then asks only questions that can change the result. This matters because Tooltip, Popover, and Hover Card may share a floating shape while requiring different interactivity and persistence rules.
The final output turns the selected pattern into an implementation contract. It records trigger, dismissal, modality, focus, keyboard behavior, placement, mobile behavior, excluded alternatives, and observable acceptance checks. Give that brief to a coding agent, then test the result instead of trusting the label alone.
Need a manual process first? Read the step-by-step guide to identifying an unnamed UI pattern.
Use the right level of language
These terms describe different levels of the same interface. Start with the UI element you can observe, move to the component a developer can build, then confirm the pattern whose behavior matches the task.
The broadest user-facing term for something visible or interactive, such as a field, button, panel, icon, or floating surface. Use it when you can describe the thing but cannot name it yet.
A reusable implementation unit in a design system or codebase. A component may expose several states and behaviors, and its library name does not always identify the underlying interaction correctly.
A repeatable solution to an interface problem. The pattern connects the visible form to expected behavior, including trigger, focus, keyboard support, dismissal, placement, and mobile adaptation.
Frequently asked questions
These answers explain the scope of the tool before you rely on a diagnosis.
A UI pattern is a repeatable solution to an interface problem with recognizable behavior and expectations. The visible shape is only one clue. Trigger, focus movement, keyboard support, dismissal, modality, placement, persistence, and content all help define the actual contract. Some familiar terms describe semantics, while others describe presentation or a behavior attached to another component.
Describe observable behavior instead of guessing a label. Note what activates it, whether it contains controls, whether users can interact with the background, what happens to keyboard focus, how it closes, whether it persists, and what changes on mobile. Use those facts to eliminate incompatible patterns before choosing the closest reviewed term.
The name is shorthand for implementation decisions. Asking for a Tooltip when users must click links inside the surface can produce an inaccessible build. Asking for a Select when users must type and filter options can block the required task. The useful outcome is not vocabulary alone; it is a behavior contract that prevents a coding agent or component library from making the wrong assumptions.
No. It returns reviewed candidates, decisive differences, a framework-neutral implementation brief, and observable checks. You still choose the component library and verify the result in your own application. The tool covers a closed set of 44 web UI concepts and can return no match when the evidence does not support a reviewed answer.