The Component Gallery
Interface components from real-world design systems
About The Component Gallery
The Component Gallery is a free reference catalogue of user interface components as they are actually built in real-world design systems. Instead of offering one more component library to install, it collects how dozens of established systems, from Shopify's Polaris and Elastic UI to the GOV.UK and Sainsbury's design systems, implement the same pieces of interface: accordions, alerts, avatars, carousels, popovers, tabs, tree views and more. At the time of writing the site lists 60 components, 95 design systems and 2,671 individual examples, each linking out to the original documentation.
The problem it solves is a familiar one for anyone building interfaces. Many interface problems have already been solved well by someone else, and naming things is hard: the same widget is an accordion in one system, a disclosure in another and an expander in a third. The Component Gallery puts those names side by side, so a designer or front-end developer can see what a pattern is usually called, how other teams structured it and which accessibility and usage notes they wrote down, before designing their own version.
The site was created by front-end developer Iain Bean and has been maintained since 2019, with a public changelog that records additions through 2026. It is deliberately not a component library: as its own About page puts it, most of these components are not ready to use off the shelf, and the aim is to inspire your own solution rather than hand you one to copy. It is built with Astro, uses Pagefind for site search and is free to use with no account.
Start from the Components index, which shows every component as a simple line illustration and can be sorted by name or by how many examples it has. Opening a component, Accordion for example, gives you its other names (Collapse, Disclosure, Expandable, Expander and more), a one-paragraph definition and a grid of real examples from different design systems, 101 of them in the accordion's case.
Each example grid can be filtered by technology and by features, then sorted by design system, so you can narrow it to React implementations with code examples or to systems that publish accessibility guidance. Longer component pages add notes on markup approaches, interactivity, styling and usage guidelines, plus links to further reading. A Copy URLs button collects the example links in one go.
The Design systems section works the other way round. It lists every system the site draws from and lets you filter by platform (GitHub, Figma, Storybook), by technology (React, Web Components, Vue, Angular, Sass, Tailwind CSS and others) and by features such as code examples, open source, usage guidelines, accessibility and tone of voice, so you can find the systems most relevant to your own stack.
- •Component index - 60 interface components, each with an illustration, a plain definition and the alternative names different teams use for it, which makes it a practical naming reference.
- •Real examples from production systems - 2,671 examples across 95 design systems, each linking to the original system's documentation rather than a copy of it.
- •Filters by technology and features - narrow any component's examples to a framework or to systems that publish code examples, usage guidelines or accessibility notes.
- •Design system directory - browse the 95 systems themselves, filtered by platform, technology and documented features, and sorted by date, name or component count.
- •Implementation notes - component pages cover markup approaches, interactivity, styling and usage guidance, with footnotes and resources for further reading.
- •Fast site search - a keyboard-driven search (Cmd or Ctrl + K) across components and systems.
The Component Gallery suits front-end developers who want to see how established teams structured a component before writing their own, designers naming and documenting components for a new design system, and design system teams benchmarking their coverage, accessibility notes or terminology against what others publish. It is also useful for anyone settling a naming argument, since the alias lists show what each pattern is most commonly called.
It is not the right tool if you want drop-in code. Nothing here installs into your project; the value is in comparison and research, and you will still build or adopt a library yourself. Teams that already follow a single mature design system may find they only need it occasionally, when they hit a component their system does not cover.
