Design tokens are the named values behind a page's look: color palette, font stacks, type scale, spacing units, radii, shadows. To extract them from any website, paste the URL into an extraction tool, let a real browser render it and read the computed CSS, then download the result as JSON, CSS, Markdown, or a Tailwind theme. The loop takes minutes.
The old version of this task was an afternoon in DevTools and a text file full of hex codes. The version below is four steps. Most of this article is about what you get back and how to read it — because the extraction itself is the easy part.
What a design token actually is
A design token is a design decision with a name. Instead of #1D4ED8 scattered across forty rules, you get color-primary: #1D4ED8 — one named value, used everywhere, changed in one place. That's the entire idea, and it's why serious design systems are built on tokens rather than raw values.
Tokens matter for extraction because they're the difference between a page's surface and its system. A screenshot gives you the surface: pixels you can look at but not measure. Tokens give you the system: the exact palette, the type ratio, the spacing unit — the values you'd need to speak the same visual language on a page of your own.
There's also a practical standard behind the format: the W3C design-token specification, a community standard for writing tokens so they move between tools without translation. One extraction, many destinations — a stylesheet, a Tailwind config, a design brief, an AI coding tool. The format is still maturing — treat it as a well-supported community draft rather than a finished standard — but it's the closest thing the industry has to a common tongue for design values.
A spacing example makes the value obvious. A page built on raw values has padding: 13px on one card and padding: 15px on the next — drift nobody chose. The same page on tokens has spacing-card: 16px in both places. When you extract from a well-built page, you inherit decisions someone already got right. When you extract from a sloppy one, the drift shows up as near-duplicate values — which is its own useful diagnostic.
What you can pull from a live page
A token extraction reads the page's computed CSS and structures what it finds into six groups:
| Token group | What it captures | What you get back |
|---|---|---|
| Color palette | Backgrounds, text, accents, borders | Named color tokens with exact values |
| Typography | Font stacks and the type scale | Heading/body sizes, line-heights, weights |
| Spacing rhythm | The base unit and its multiples | The spacing scale, e.g. 4 / 8 / 16 / 24 / 32 |
| Border radii | The corner system | Button and card radius values |
| Shadows | The elevation recipes | The shadow values the page reuses |
| Component styles | How tokens combine on UI parts | Button and input style patterns |
Six groups is the whole target. With those in hand, the "look" of the page stops being a feeling and becomes a spec you can hand to someone — or to something.
The four-step extraction flow
Using Design Extractor, in its free tokens mode:
- Paste the URL of the landing you want to read.
- Run the extraction. A real browser renders the page first, so what gets read is computed styles — the final values the browser applied — not guesses from source code. JavaScript-heavy pages render before reading; more on that in the limits section.
- Open the result. You get the six token groups, plus four export files.
- Download the files, or send the extraction onward. The send-to-Forge option hands the tokens to the platform's white-page generator, which builds a page in the same design DNA.
For a first run, pick a page you know well — your own landing is ideal. You already know what it should contain, so the result is easy to sanity-check: if the palette and type scale match your expectations, the method does what it says. Then point it at pages you don't know.
Notice what the slow part isn't: the reading. The slow part of this job is deciding what to do with the result, and that's a workflow question, not a tool question.
One habit worth building: re-run the extraction after any major redesign of your own pages. The token set becomes the changelog — a diff between two extractions shows what the redesign actually changed, which is rarely what the mockup said it would change.
Reading the output: what each file is for
Four files come back. They overlap on purpose — each exists for a different consumer:
| File | Format | Who it's for |
|---|---|---|
| tokens.json | W3C design-token JSON | Tools — the canonical, machine-readable source |
| tokens.css | CSS custom properties | Your stylesheet — drop in and reference |
| Markdown spec | Human-readable document | People — paste into a brief or an AI chat |
| Tailwind theme | Tailwind theme object | Tailwind builds — the config layer |
My own pattern, if it helps: the Markdown spec goes into the project notes immediately, because it's the version I'll actually re-read. tokens.css goes to whoever builds the page. tokens.json is the file I archive. The Tailwind theme only matters when the build is Tailwind — and when it is, it removes the most tedious step of the setup.
One practical note on tokens.css: the values arrive as custom properties, so the rebuild references them by name instead of pasting hex codes around. That sounds like a small thing. Six weeks later, when the page needs a palette tweak, it's the difference between editing one line and hunting forty.
Where extraction reaches its limits
Honest boundaries, because every tool has them:
- JavaScript-heavy pages: covered. The capture harness is Playwright with scroll-hijack handling — the same one AdInfraCheck uses for its screenshots — so single-page apps finish rendering before anything is read.
- Complex animation: partially covered. Animation behavior can be incompletely detected. When that's the case, the result lists the known limitation instead of silently guessing.
- Login walls and gated content: not covered. The browser sees what a fresh visitor sees. If the interesting part sits behind a login, it isn't publicly rendered, and there's nothing to extract.
- Assets and layout: deliberately excluded. Free tokens mode doesn't download the site's images or clone its layout. If what you need is the page's structure — section by section, with asset references and animation behavior — that's the paid prompt mode, which reverse-engineers the page into a rebuild prompt for AI builders. Start with tokens; they cover most "I want this look" jobs.
Worth saying plainly: output quality tracks the source page's discipline. A page built on a real design system yields a tight token set — a handful of colors, a clean scale. A page assembled by accretion yields forty near-identical grays. The extraction is honest about what it finds; interpreting the mess is still your job.
If you're extracting tokens from several pages, the next problem is organizing them so they turn into pages instead of clutter — that's the swipe-file workflow. And if you're wondering where legitimate extraction ends and cloning begins, the piece on reverse-engineering a design system draws that line.
FAQ
Are extracted tokens the site's actual source code?
No. The extraction reads computed CSS — the values the browser settled on after all styles resolved — and structures them into tokens. You get the design system as measurements, not the site's files.
What format is tokens.json?
The W3C design-token format — a community standard for portable design tokens. It's written to be consumed by tools: builders, code generators, AI coding assistants.
Can I use the tokens in Tailwind?
Yes — that's what the Tailwind theme export is. It maps the extracted palette, type scale, and spacing into the theme layer of a Tailwind config, so the rebuild speaks the same design language from the first commit.
Does it work on single-page apps and JavaScript-heavy pages?
Yes. The capture harness renders the page in a real browser (Playwright, with scroll-hijack handling) before reading computed styles, so JS-rendered content is captured. Complex animation detection can be incomplete — the result flags it when so.
What's the difference between free tokens mode and the paid mode?
Tokens mode extracts the design system: colors, typography, spacing, radii, shadows, component styles. The paid mode goes further — it reverse-engineers the page section by section (structure, asset references, animation behavior) into a rebuild prompt for AI builders. Tokens first; pay only when you actually need structure.
Extract your first set of tokens
Pick a page you've been meaning to study and run it: Design Extractor is free with an account. Paste the URL, read the six token groups, download the four files. The read takes minutes — deciding what to build with it is the part worth your afternoon.