How to Extract a Design System from Any Website

You found a site with a look you admire, and you want to understand how it's built — the exact purples, the type scale, the spacing rhythm, the corner radii. You can reconstruct a lot of that from its public CSS. This guide explains what a design system contains, how to pull observed values out of a live site, and — importantly — where static extraction stops. You can follow along on any public URL with Website → Design System.

What a design system actually contains

A real design system is more than colors and fonts. It's a documented, intentional set of decisions — tokens, components, usage rules and rationale — maintained by a team. What you can extract from a website is the visible residue of that system in its CSS: the values actually used on the page. That's genuinely useful, but keep the distinction in mind from the start — see "extracted ≠ official" below.

Colors

Colors live in CSS as hex, rgb()/rgba(), hsl(), named keywords and gradient stops. Extraction means parsing every color declaration and custom property, normalizing to a canonical form, de-duplicating, and counting occurrences. A color used 40 times is "frequently used" — that's an observation, not proof it's the brand's official "primary."

Typography

The typographic system shows up as font-family stacks (often behind a CSS variable like --font-sans), a scale of font-size values, a set of font-weights, plus line-height and letter-spacing. Collecting and sorting these reveals the type scale the site actually renders.

Spacing

Margins, paddings and gaps cluster around a spacing scale — often multiples of 4 or 8px. Counting how often each value is used (not just declared) surfaces the real rhythm, and makes rare one-off values stand out as possible mistakes.

Border radius

Corner radii are a small but telling system: a handful of steps from 0 through a few pixel values up to a full pill (9999px). Extracting them, with counts, shows the rounding language at a glance.

Shadows

box-shadow (and text-shadow) values define elevation. Grouping near-identical shadows together highlights whether the site uses a tidy set of a few elevations or a sprawl of slightly different ones.

CSS custom properties and design tokens

This is the highest-fidelity signal. When a site defines real CSS variables — --brand-500, --radius-md, --space-2 — those are tokens, and they should be preserved exactly, with their names and values, separate from values merely observed from usage. A good extractor never renames them or invents new ones; any generated names should be clearly marked as generated (for example with an --ems-extracted- prefix) so you always know what came from the site and what the tool created.

UI patterns

Beyond raw values, you can detect recurring components — buttons, cards, inputs, links, badges — from multiple signals: the semantic element, class-name hints, and the resolved CSS and structure. Tag names alone lie (a <div class="card"> isn't always a card), so evidence should be combined and each detected pattern should carry a confidence and an evidence level rather than a confident guess.

Detecting inconsistent styles

Once you have the observed values and patterns, inconsistencies emerge: near-duplicate colors that differ by one hex digit, a spacing value used twice next to two that dominate, buttons that mostly use an 8px radius but occasionally 12px. Report these conservatively — flag only where there's clear evidence, because plenty of variation is intentional. Resist the urge to compute a subjective "consistency score"; a count of evidence-backed findings is more honest.

Turning observed styles into reusable components

Extraction becomes practical when you can round-trip it: take a detected pattern's representative styles, render it live, tweak the color/radius/padding, and copy the result as CSS or HTML. A playground like this turns "here's what their button looks like" into "here's a button I can adapt" — grounded entirely in observed values, not AI guesses.

Exporting CSS and JSON

The output should be portable: CSS custom properties for dropping into a stylesheet, and deterministic JSON for tooling. Crucially, exports should contain only design values and source metadata — never cookies, headers or private data. Determinism matters too: the same page should always produce the same tokens.

The limitations of static extraction

Static analysis reads the HTML and CSS as served — style blocks, inline styles and linked stylesheets. It will miss styles injected at runtime by JavaScript, values computed only after interaction, and anything behind authentication. A page that builds its UI entirely in JS may expose very little to extract. Good tooling tells you when coverage is limited instead of pretending the result is complete.

Extracted ≠ official

This is the credibility line. Extracting a site's observed values is not the same as reconstructing its official design system. The team's real system includes intent, naming, usage rules and components you can't see in CSS. Treat extracted output as a well-evidenced starting point — perfect for learning, prototyping and consistency-checking — and never claim it is the source's design system.

When manual inspection is still necessary

Use your browser's DevTools to confirm how a token cascades, to inspect states (hover, focus, disabled) that static extraction can't reach, and to understand JS-driven styling. Pair extraction with a technical website QA pass if you're auditing a site end-to-end, and read the FAQ for exactly what the extractor does and doesn't do. Then try it on a site you like with Website → Design System, or explore the other free tools.