Guide · how-to
how to extract design tokens from any website
Pointing a tool at a live page and getting its colors and type back is easy. The gap between the tools shows up in what happens next: whether you get a panel to eyeball, a JSON file to import, or a brief your AI agent can actually build from. This walks through every honest option for pulling design tokens off a website, what a good export should contain, where the legal line sits, and then a clean uiscanner path for when the next step is code.
what a design token export should actually contain
A design token is a named value that stands in for a design decision: not #635bff, but the fact that this hex is the primary action color. The designtokens.org format module groups them into families, and a report is only useful if it covers all of them:
| Family | What to pull | Watch out for |
|---|---|---|
| Color | Brand, surface, text, border, states | Dozens of near-duplicates that should collapse to a few |
| Typography | Families, the size scale, weights, line height, tracking | The rendered scale, not every one-off size in the CSS |
| Spacing | The padding and gap rhythm (often a 4px or 8px step) | Random values that break the scale |
| Radii | Corner radius per component tier | |
| Shadows | Color, x and y offset, blur, spread, layered stacks | |
| Motion | Durations and easing curves | Almost every tool skips this |
The last row is where most exports quietly stop. Project Wallace and CSS Stats are excellent at the first five and honest that they extract "every color, font-size, shadow and spacing value" from the stylesheet, but a raw dump of the CSS is not a design system. The work is turning that dump into a scale a human or a model can build against.
the four ways to do it
1. browser DevTools, by hand
Open the inspector, click an element, read the computed styles, write the value down. It costs nothing and it is the most accurate reading of one element you will get. It is also slow: reconstructing a full token set this way runs 30 to 45 minutes, and you are the one deciding which of the fourteen greys is the real text color. Good for spot checks, painful for a whole system.
2. browser extensions
Tools like Peek, CSS Peeper, Snable and the various "design extractor" plugins put a designer-friendly panel over DevTools: color palette, fonts, spacing, sometimes a logo and asset grab, often a Figma handoff. Peek's own writeup frames the job well, extract colors, typography and assets, then copy or download them. These are fast and pleasant when a person is the one doing the next step. The output is still a panel you read and retype.
3. crawlers and CSS analyzers
Project Wallace and cssstats.com take a URL, statically analyze the CSS, and produce a comprehensive report: every color grouped, every font size, frequency counts, histograms showing where the system is consistent and where it is quietly drifting. Project Wallace even has an open-source css-design-tokens package that emits DTCG-spec JSON. This is the most rigorous option for auditing your own CSS. The limit is that it reads the stylesheet, not the render, so it lists values that technically exist but never actually show up on screen, and it has no idea which button is the real primary.
4. CLI and agent tools
The newest lane. Node CLIs and AI-agent skills (Claude Code, Cursor, Codex) that scan a public page and emit tokens as JSON or CSS custom properties, so the values land straight in a repo instead of a panel. This is the right shape when the thing consuming the tokens is not a human but a coding agent, because the agent never saw the panel and cannot retype from it.
the transformative line, briefly
Design token values, a hex code, a 16px size, an 8px radius, are functional CSS, not copyrightable creative expression, so reading them for reference is generally fine. The line is trade dress: a pixel-perfect clone that copies the original's asset bytes and identity can raise real problems. The safe posture, and the one every reputable tool in this space takes, is transformative. Describe and tokenize the page, rebuild in your own stack from the tokens and structure, and never re-host the original's images or fonts. Use what you pull as a starting system and make the design your own.
the uiscanner walkthrough
uiscanner sits in that fourth lane, built for when the next step is an AI building a page rather than a person reading one. Paste any public URL and you get three things back: the tokens (colors, fonts, the type scale, radii, spacing, shadows, motion), a section-by-section map of how the page is assembled, and a build prompt tailored to recreate the look. It is transformative by design: it describes and tokenizes, and never copies or re-hosts the original site's asset bytes.
The part that separates it from a CSS crawler is that it reads the rendered page with vision plus the DOM, not just the stylesheet. That is how it catches the real primary button instead of the first one in the source, tells a centered hero from a split one, and flags decorative imagery with prompts to recreate it as originals. A code scraper misses all three.
on the web
Scan straight from the address bar. Put a URL after the domain and it runs:
uiscanner.com/https://stripe.com
Every scan returns an id and a shareable uiscanner.com/t/<id> link. Browse example teardowns to see the output first, including full breakdowns of the Stripe and Linear design systems.
via the CLI and MCP
To put tokens where your coding agent can act on them, wire in the MCP server and CLI. One line connects it to Claude Code:
claude mcp add uiscanner -- npx -y uiscanner-mcp@latest
Or run a one-off scan from the terminal without any setup:
npx -y uiscanner-mcp@latest scan stripe.com --target landing
The MCP surface exposes five tools. ui_probe(url) is a cheap preflight that spends no scan, so you can check a page is reachable before committing. ui_teardown(url, target?) runs the full scan and returns the id, link, tokens, structure and prompt as structured data. get_teardown(id) re-fetches a finished one. retarget_teardown(id, target) re-tailors the build prompt to a different archetype (landing, dashboard, marketing, ecommerce, portfolio, mobile, general) without re-scanning, which is far cheaper than a second scan. whoami() reports your plan and remaining scans. The server is stdio-only and works as a client tool for Claude Code, Cursor and Codex.
The payoff over a panel: your agent scans the URL and receives the whole system in one call, then builds against a real design language instead of the generic defaults every model ships by default. That is the loop a color panel cannot close, and it is spelled out further in uiscanner vs Snable.
picking the right one
- Auditing your own CSS for drift? Project Wallace or CSS Stats. Nothing beats a static analyzer with histograms for finding the twelfth grey.
- Grabbing a palette or moving colors into Figma? A browser extension like Peek or Snable. Fast, human, done.
- Feeding a reference to a coding agent? uiscanner. It reads the render, keeps the structure, writes the prompt, and hands it all to Claude Code, Cursor or Codex as data.
A quick note on quota so nothing surprises you: uiscanner's free plan is 5 scans per rolling 30 days, with Indie ($12/mo) at 100 and Studio ($39/mo) at 400, and that quota is shared across the web app, MCP and CLI. Point it at a page worth learning from and let your agent build from a real system.