# Get design tokens from a live website

[Open the live Fudge conversation](https://design.withfudge.com/share/get-the-design-tokens-from-a-live-website)

Last updated: 2026-08-25

You can get design tokens from a live website by capturing the page, checking its visible styles, and separating repeated values from one-off decoration. The useful result is a practical token sheet covering color roles, typography, spacing, borders, radii, shadows, and component states.

## Start with the tokens that affect every screen

Use this order so the result becomes useful quickly:

1. **Colors:** identify the page background, raised surfaces, primary text, muted text, borders, links, buttons, success, warning, and danger colors.
2. **Typography:** record font families, available weights, heading sizes, body sizes, line heights, and letter spacing.
3. **Spacing:** look for repeated gaps and padding values around navigation, cards, forms, sections, and buttons.
4. **Shape:** note border widths, corner radii, shadows, and repeated focus, hover, selected, or disabled treatments.
5. **Components:** map the tokens to buttons, inputs, cards, navigation items, badges, and alerts.

This order prevents a common mistake: collecting dozens of hex values while missing the roles those values play. Start with the page regions and components that repeat, then record the values that support them.

The Linear reference shows a compact sans-serif direction, with Inter used for body copy and controls at one weight and emphasized interface text at a heavier weight. Treat this as an observed reference, not proof that every Linear product surface uses exactly the same system.

## Captured pages

[![The system for product development](https://pin.fontofweb.com/6434?format=jpg)](https://design.withfudge.com/share/pin-6434)

[The system for product development](https://design.withfudge.com/share/pin-6434)

## Linear typography

- **Inter** — weight 400 · Body copy, labels, navigation, and controls.
- **Inter** — weight 500 · Headings and emphasized interface text.

## Make a token sheet instead of a screenshot list

A good token sheet explains where each value belongs. Use a table like this:

| Category | Token | Value | Use |
|---|---|---|---|
| Color | `color.text.primary` | observed value | Main headings and readable content |
| Color | `color.text.muted` | observed value | Supporting copy and metadata |
| Color | `color.surface.raised` | observed value | Cards, menus, and panels |
| Type | `font.body.family` | observed family | Paragraphs, labels, and controls |
| Type | `font.heading.weight` | observed weight | Titles and emphasized text |
| Space | `space.md` | repeated value | Common control and card spacing |
| Shape | `radius.md` | repeated value | Cards, inputs, and buttons |

Use roles rather than names such as `green-3` or `gray-7`. A role survives a redesign better because it tells the next person what the value does. If two values look similar but appear in different contexts, keep both until you verify whether they are interchangeable.

## Check the page in context

A token is useful only when you know its behavior. Check the same color on light and dark surfaces, large and small text, disabled controls, hover states, and selected states. Check type at the actual sizes used in headings, navigation, labels, and body copy. Check spacing at narrow and wide viewport sizes so responsive changes are not mistaken for a separate base scale.

Separate observed facts from assumptions. A captured page can show that a heading uses Inter at a particular weight, but it may not prove that Inter is the official font for every product surface. Likewise, a visible color can be recorded as an observed value without claiming that it belongs to the site's complete internal design system.

## Turn observations into implementation-ready values

After checking the page, normalize the results into a small set of names and preserve the raw observation beside each one. A useful export should answer three questions: where was the value seen, what role does it serve, and which components depend on it?

For a new interface, start with six to ten color roles, three to five text roles, a short spacing scale, a few radii, and two or three shadow levels. Add exceptions only when the page repeatedly uses them. This keeps the extracted system usable instead of turning every visual difference into a token.

## Use this in your AI agent

> Inspect the captured website and extract a practical design token sheet. Return color roles, typography families and weights, repeated spacing, border widths, radii, shadows, and component states. Separate observed values from assumptions, preserve the page context for each token, and format the result as CSS variables with a short DESIGN.md explanation.

For a repeatable workflow, [install Fudge for your AI agent](/mcp) and give it the captured page you want to review.

---

Start with values that repeat across the page and affect the most components. Extract primary and muted text, page and raised-surface colors, the main action color, border color, body and heading fonts, common font weights, heading and body sizes, line heights, control height, common padding, card radius, and the main shadow.

Check whether each value appears in at least two places. A color used for a button and an active navigation item may be a shared action role. A color used only for one illustration is probably not a core token. Do the same for spacing: repeated gaps between navigation items, card content, form fields, and sections are stronger candidates than a one-off large margin.

Keep an evidence note for every value, such as "used on primary button and active navigation item" or "seen in card borders at two viewport sizes." This makes later review faster and prevents a visual guess from becoming a permanent variable.

---

First, group values by purpose rather than by the order in which you noticed them. A simple structure is `--color-*`, `--font-*`, `--text-*`, `--space-*`, `--radius-*`, `--border-*`, and `--shadow-*`. Use semantic names such as `--color-text-muted` and `--color-surface-raised`, not names tied to a screenshot position.

Keep the observed value and proposed token name together during review. Merge near-duplicates only when they have the same role and behave the same way in context. If two colors differ slightly but one is used for borders and one for disabled text, keep them separate.

Finally, add a small component map. Record which button, card, input, or navigation state uses each token. This turns a CSS file into a maintainable starting point while making clear that it is an observation of the captured page, not proof of the website's official internal design system.

## Related questions

- [Get Gradient Styles From a Live Website](/share/get-the-gradient-styles-from-a-live-website)
- [Get Interaction Patterns from a Live Website](/share/get-the-interaction-patterns-from-a-live-website)
- [Get a Design System from a Live Website](/share/get-the-complete-design-system-from-a-live-website)
- [Get the page layout from a live website](/share/get-the-page-layout-from-a-live-website)