Capture design tokens from a live website for reuse

Contents

• [Build the token set in layers](#build-the-token-set-in-layers)
• [Compare before naming tokens](#compare-before-naming-tokens)
• [Make the tokens implementation-ready](#make-the-tokens-implementation-ready)
• [Check the result before reuse](#check-the-result-before-reuse)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

To capture design tokens from a live website for reuse, collect repeated visual values by role, compare them across components and pages, and label what is observed versus what still needs verification. The goal is a usable set of typography, color, spacing, border, radius, shadow, and layout decisions, not a claim about the site's private source files.

Build the token set in layers

Start with values that affect the whole interface:

• Font families and available weights
• Body and heading sizes
• Line heights and letter spacing
• Page and surface colors
• Primary and muted text colors
• Accent, success, warning, and danger colors
• Common spacing steps
• Border widths and divider colors
• Corner radii
• Shadows, glows, or flat surfaces
• Content width and major layout gaps

Then connect each value to visible uses. A dark color is more useful when recorded as a page background, raised surface, or control background. A pale color is more useful when identified as primary text, muted text, or a border. Role-based notes make the result easier to reuse in a different page structure.

The captured Linear reference and typography evidence provide a concrete starting point. The supplied font evidence identifies Inter at regular weight for body copy, labels, navigation, and controls, with a medium weight for headings and emphasized interface text. Treat these as observed inputs from the captured reference. Exact token names and the complete internal scale still need verification.

Compare before naming tokens

Do not turn the first visible value into a global token immediately. Compare it in at least three places:

1. A primary component, such as a button or card
2. A supporting component, such as a field, navigation item, or divider
3. A different section or page state

If the same color or spacing value appears repeatedly, it may be a shared decision. If it appears only once, keep it as a local value until more evidence is available. The same check applies to typography. A large heading may be a display treatment rather than the top step in the site's full type scale.

For spacing, measure relationships rather than isolated gaps. Record page padding, section spacing, card padding, control height, label-to-input spacing, and grid gaps. Look for a compact group of values that can become a working scale. Keep unusual editorial spacing separate so it does not distort every component.

Pay attention to contrast and hierarchy. Document relationships directly: primary text is stronger than muted text, a raised surface is separated from the page background, and a selected control remains clear without overpowering the main content.

Make the tokens implementation-ready

A simple token table can use four columns:

Add sizes, line heights, spacing, and shape values as they become available. Keep the raw value beside the role name. This lets a developer implement the system while preserving a direct path back to the reference.

If the team uses CSS, map the table to custom properties. If it uses Tailwind v4, map the roles to theme variables and check the rendered result against the captured page. If the team prefers documentation, create a DESIGN.md with examples and state notes. An exported file is a useful handoff, but it represents observed design details. It does not establish ownership of an official internal design system.

Check the result before reuse

Use this final review:

• Can every token be traced to a visible example?
• Are color roles clearer than raw values alone?
• Are typography family, weight, size, and line height separated?
• Does the spacing scale cover common components without forcing exceptions?
• Are mobile changes documented separately?
• Are hover, focus, active, disabled, and error states included where relevant?
• Are one-off marketing treatments kept out of the core set?
• Are uncertain values marked for verification?
• Does a test component still resemble the reference after the tokens are applied?

A good token set should help someone build a new screen without repeatedly returning to the original page. It should also make differences easy to explain when the new screen needs its own content, accessibility treatment, or responsive behavior.

Use this in your AI agent

> Inspect the captured website references and extract a reusable token set. Group observed typography, colors, spacing, borders, radii, shadows, layout widths, and component states by role. Compare repeated values across pages, separate global patterns from one-off treatments, include confidence and source context, and format the result for a Tailwind v4 theme, CSS variables, and a short DESIGN.md handoff.

Install Fudge for your AI agent to inspect captured references and prepare the token handoff.

Capture the foundation first: font family, body and heading weights, main text colors, page background, surface background, accent color, divider color, common spacing, control height, radius, and content width. These values influence nearly every component and give you the fastest route to a consistent new screen.

Next, capture the most repeated components: buttons, links, fields, cards, navigation, and section headings. Record their padding, gaps, borders, shadows, and states. Do not spend early effort on a one-off illustration or a single promotional block unless that treatment is part of the work you are recreating.

With limited evidence, keep the token set small. A compact scale with clear roles is more useful than a long list of guessed values. Mark each item as high, medium, or low confidence based on repetition and visibility. Once you have more pages or states, refine the scale rather than replacing it without comparison.

The Linear evidence is a useful example of a compact sans-serif grouping with contrast created through weight and size. Use it as an observed reference, not as a universal template.

Build a small test screen before applying the tokens across a full product. Include a page heading, body paragraph, primary and secondary buttons, a field, a card, a divider, a selected state, and an error or warning example. This exposes problems in hierarchy, contrast, spacing, and state treatment quickly.

Compare the test screen with the reference at the same viewport sizes. Check whether headings occupy a similar amount of space, whether controls feel equally compact, whether surfaces separate clearly, and whether muted text remains readable. Also test a narrow viewport so the spacing scale does not create cramped controls or excessive empty space.

Then review the exceptions. If several components need unique overrides, your base tokens may be too narrow or your component rules may be mixing layout with visual styling. If everything looks flat, revisit text contrast, surface separation, borders, and shadows before adding more colors.

Keep a short verification list beside the token file. Name the reference screen, viewport, components checked, unresolved values, and the person responsible for confirming them. This turns visual comparison into a repeatable review.

Related questions

• Capture Gradient Styles from a Live Website for Reuse
• Capture a Website Color System for Reuse
• Extract a Website Typography System from a URL
• Website Spacing Scale Extractor from URL