Web UI Examples: Galleries, Design Systems, and Code You Can Use
Find web UI examples you can study or build from, then choose patterns by code quality, accessibility, maintenance, licensing, and project fit.
Web UI examples serve two different needs: discovering visual patterns and finding implementation guidance you can actually build from. A gallery is useful for browsing ideas. An official design system usually adds coded components, design tokens, accessibility expectations, content guidance, and task patterns.
Use examples as evidence for a design decision, not as automatic proof that a component is accessible, reusable, or licensed for your project. The strongest choice depends on your framework, audience, product constraints, maintenance capacity, and license requirements.
What counts as a useful web UI example?
A useful example gives you enough context to answer at least one practical question:
- Visual discovery: What could a form, navigation pattern, card, table, or empty state look like?
- Interaction behavior: What happens on focus, validation failure, loading, mobile widths, keyboard navigation, or an error?
- Implementation: Is there HTML, CSS, JavaScript, React, Vue, or another framework example you can adapt?
- Content and task guidance: Does the source explain labels, instructions, ordering, and when to use the pattern?
- Constraints: What accessibility, browser, performance, license, or brand assumptions does the source make?
A screenshot alone answers mostly the first question. A maintained design-system page can answer several.
Where to find web UI examples
The Component Gallery: broad visual discovery
The Component Gallery is a broad directory for comparing components and design systems. Its search result reports 60 components, 95 design systems, and 2,671 examples (accessed 2026). These figures are directory counts and can change, so treat them as a snapshot rather than a quality score.
Use it when you want to see how different systems approach the same component. Open the underlying design-system source before copying anything. The gallery helps with discovery; it does not certify that every listed implementation is accessible or suitable for production.
GOV.UK Design System: task-focused public services
GOV.UK Design System provides styles, reusable components, and patterns for government services, including forms and navigation. Its guidance is especially useful for studying task completion, clear content, and predictable service flows.
Its context matters. Government users, service rules, content standards, and branding shape the recommendations. Adapt the underlying task pattern to your audience instead of copying the visual treatment unchanged. The site also describes a brand refresh that began in June 2025 and related frontend releases, so check the current guidance when you adopt an example.
U.S. Web Design System: tokens, components, and implementation guidance
USWDS presents components, patterns, design tokens, utilities, and implementation guidance for accessible, mobile-friendly federal websites. Its overview lists sites built with USWDS and describes an open-source community serving dozens of agencies and nearly 200 sites. Those adoption figures are claims from USWDS itself, not an independent audit.
USWDS is a useful reference when you need a broader system rather than isolated screenshots. Review its markup, tokens, responsive behavior, and accessibility notes alongside your own framework and content model.
The National Archives Design System: coded examples with context
The National Archives Design System describes components as reusable interface parts and provides coded examples with contextual guidance. Its component pages include accordions, back links, breadcrumbs, and form inputs. This makes it useful for comparing both appearance and intended usage.
Gallery versus design system
| Question | Gallery | Official design system |
|---|---|---|
| Can I browse many visual directions quickly? | Usually yes | Usually within one system |
| Is source code included? | Sometimes; verify each entry | Often, with a supported stack |
| Are interaction states documented? | Rarely | Often |
| Is accessibility guidance included? | May be a discovery hint only | More likely, but still validate your implementation |
| Can I reuse the code? | Depends on the original source | Depends on the system’s license and terms |
| Who maintains it? | Directory maintainer and listed projects | The organisation or open-source community behind the system |
Start with a gallery when the problem is “What patterns exist?” Move to a design-system source when the problem becomes “How should this behave and how do I implement it?”
How to evaluate an example before using it
- Identify the purpose and context. Determine whether the pattern is general-purpose or designed for a government service, commerce flow, dashboard, marketing page, or another setting.
- Inspect the implementation. Look for semantic HTML, responsive behavior, focus styles, keyboard interaction, validation states, loading states, and an explanation of required JavaScript.
- Check framework fit. Confirm whether the source supports your stack or only provides visual inspiration. A React component may not map directly to a server-rendered application, and a CSS utility example may assume a particular build pipeline.
- Read accessibility guidance. Check labels, names and descriptions, focus order, keyboard operation, contrast, reduced-motion behavior, error messaging, and screen-reader expectations. A directory accessibility tag is a discovery hint, not proof that your final implementation is accessible.
- Review maintenance signals. Look for release notes, issue activity, migration guidance, versioning, and a clear source repository or documentation owner. Recent releases can change markup or tokens.
- Verify the license. Read the source project’s license and terms. Public visibility does not imply unrestricted reuse, redistribution, or commercial permission.
- Prototype the risky state. Test the pattern at narrow widths, with long labels, empty data, failed requests, validation errors, keyboard-only input, zoom, and high text size before committing to it.
A practical workflow for turning examples into a component
1. Define the task
Write the user goal, required data, success condition, and failure paths. “Choose a delivery address” is more actionable than “build a nice card.”
2. Collect several references
Compare at least three examples for the same task. Record what changes between them: hierarchy, density, labels, actions, responsive layout, and states.
3. Separate invariant behavior from styling
Document keyboard behavior, focus management, validation, and state transitions separately from colors, borders, spacing, and typography. This makes adaptation safer when your brand or framework changes.
4. Build the smallest semantic version
Start with native elements where they fit: <button>, <label>, <input>, <nav>, headings, lists, and tables. Add custom interaction only when the task requires it.
5. Test states and content extremes
- Keyboard focus and tab order
- Screen-reader names, descriptions, and announcements
- Validation before and after submission
- Loading, empty, partial, and error data
- Long translations, large text, zoom, and narrow screens
- Reduced motion and touch targets
6. Record provenance
Keep the source URL, version or access date, license, and any changes you made. This helps future maintainers update the component and explain why it behaves as it does.
Capturing examples for review and documentation
When a team needs to compare live examples, a repeatable screenshot process is useful. A browser-based workflow should wait for the page to settle, set a consistent viewport and device scale, and capture the relevant state rather than an arbitrary first paint. For dynamic pages, document the URL, viewport, theme, authentication state, and any actions performed before capture.
For a local browser workflow, Playwright can provide that control. The following Node.js script captures a full-page example after network activity settles:
import { chromium } from 'playwright';
const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1440, height: 900 } });
await page.goto('https://component.gallery/', { waitUntil: 'networkidle' });
await page.screenshot({ path: 'ui-example.png', fullPage: true });
await browser.close();Use a selector wait when the page has a known readiness element, and avoid treating a timeout as a valid screenshot. For authenticated or stateful examples, supply credentials through your test environment and never commit secrets.
Common problems and fixes
| Problem | Likely cause | Fix |
|---|---|---|
| The gallery looks good but provides no usable code | It is a discovery directory | Open the linked design-system source and search for implementation and usage guidance. |
| The component breaks on mobile | The example assumes a fixed viewport or short labels | Test narrow widths, long content, zoom, and translated strings before adoption. |
| Keyboard users cannot operate it | Custom clickable elements or missing focus management | Prefer native controls; add explicit keyboard behavior and visible focus states, then test with keyboard only. |
| Screen readers announce confusing errors | Errors are visual-only or not associated with fields | Connect error text to the input, provide a useful name, and announce submission results where needed. |
| Copied code conflicts with your framework | Different DOM, CSS reset, build tooling, or state model | Port the behavior and semantics first; translate styling and state management to your stack. |
| A dependency is unmaintained | No recent releases, owner, or issue response | Prefer a maintained source, vendor only the necessary code, and record an upgrade plan. |
| Reuse creates a licensing problem | License was assumed from public visibility | Read the original license and terms and retain required notices. |
| Automated screenshots show cookie banners or chat bubbles | The capture sees the same overlays as a first-time visitor | Handle consent and overlays in the browser script, hide known selectors, or use the ScreenshotNeo workflow below. |
Performance, reliability, and cost considerations
- Performance: Keep examples small enough to load quickly, avoid unnecessary JavaScript, and measure the real component in your application rather than relying on a gallery preview.
- Reliability: Pin important dependencies, keep a source URL and version, and add visual or interaction checks for states that matter to users.
- Screenshot repeatability: Fix viewport, device scale, theme, fonts, locale, and wait conditions. Dynamic ads, rotating content, and consent overlays can make captures differ between runs.
- Cost: Browser automation consumes compute and maintenance time. An API can reduce setup work, but compare its billing rules, output formats, caching, and failure handling with your volume and retention needs.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. It accepts one GET request and returns a PNG, JPEG, WebP, or PDF. Before capture, it accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and whether the request was billed.
Here is the one-call example. See the ScreenshotNeo documentation for the full parameter list.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://component.gallery/ -o ui-example.webpimport requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://component.gallery/"}, timeout=90)
open("ui-example.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://component.gallery/' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);Options include full-page or element capture, dark mode, device presets or custom viewports, retina scale, custom CSS and JavaScript, clicks, selector or network-idle waits, hidden selectors, blocked requests, headers, cookies, user agents, authorization, timezone, geolocation, transparent backgrounds, resizing, selectable cache TTLs, signed image links, asynchronous jobs with signed webhooks, bulk capture of up to 100 URLs per call, PDF settings, HTML/CSS rendering, and a usage API. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
There are 1,000 free screenshots each month with no card. Paid plans start at $5 for 3,000 screenshots; yearly billing gives two months free, and every feature is included on every plan. Create a free ScreenshotNeo account.
FAQ
Are web UI galleries the same as design systems?
No. Galleries focus on discovery across many sources. Design systems usually include implementation, usage, and accessibility guidance for a maintained system.
Can I copy an example directly into a product?
Only after checking its license, dependencies, framework assumptions, accessibility behavior, and maintenance status.
Which system is best?
There is no universal choice. Match the source to your audience, task, framework, accessibility needs, governance, and ability to maintain it.
How do I preserve an example for a design review?
Record the source URL and access date, fix capture settings, and save the relevant state with its license and implementation notes.
