# Extract a Website's Design Tokens

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

Last updated: 2026-08-25

To extract a website's design tokens, identify repeated visual values and assign each one a clear role, such as page background, primary text, control radius, or section spacing. Compare multiple pages before treating a value as shared, then keep the observed value separate from any assumption about the site's private source files.

## Extract roles before values

Begin with the roles that shape the whole interface:

- **Typography:** font families, weights, sizes, line heights, and casing
- **Color:** page background, surfaces, text levels, borders, accents, and feedback
- **Spacing:** container padding, section gaps, control gaps, and grid gaps
- **Shape:** control heights, border widths, radii, and divider treatment
- **Depth:** shadows, overlays, gradients, and elevation differences

A role-based list is more useful than a long list of hex values. "Muted border used around cards and inputs" tells you where a value belongs. A value copied without a role is difficult to reuse and easy to misapply.

The captured Linear example below is useful for this process because it shows a near-black canvas, muted dividers, compact controls, and one cool accent. The typography example identifies Inter in regular and medium weights, with regular text used for body copy, labels, navigation, and controls, and medium weight used for headings and emphasized interface text. Treat these as observed reference details, then compare them with your own capture before adopting them.

## 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.

## Build a token worksheet

Use one row per candidate token:

| Role | Observed value | Where it appears | Confidence |
|---|---|---|---|
| Page background | color or description | Full page canvas | High, medium, or low |
| Raised surface | color or description | Cards, panels, menus | High, medium, or low |
| Primary text | color and typography | Headings and key labels | High, medium, or low |
| Secondary text | color and typography | Supporting copy and metadata | High, medium, or low |
| Accent | color and usage | Links, actions, selected states | High, medium, or low |
| Control radius | approximate value | Buttons, fields, cards | High, medium, or low |
| Spacing step | approximate value | Repeated gaps and padding | High, medium, or low |

Use a role only when the same treatment appears in more than one relevant place. If a bright color appears in one illustration, record it as illustration-specific instead of calling it the brand accent. If two surfaces look similar, keep them separate until another page shows that they are interchangeable.

## Check typography and contrast together

Typography tokens are not just font names. Record the family, available weights, size, line height, and where each combination appears. A page may use one family with different weights for hierarchy, as the Linear example suggests. Note whether headings are larger, heavier, tighter, or simply brighter than body text.

For colors, note the relationship between roles. Primary text should be distinguishable from secondary text, surfaces should separate from the page background, and borders should remain visible without overpowering content. If you cannot verify contrast from the available reference, mark it for a later check rather than claiming an accessibility result.

## Validate tokens across pages

Create a second column for page names and mark every occurrence. A token is a stronger candidate when it appears across navigation, content, and controls. A spacing step is stronger when it repeats between sections and inside components. A radius is stronger when buttons, fields, and cards share a recognizable curve.

Finish by dividing the worksheet into three groups: shared tokens, component tokens, and page-specific values. Shared tokens can guide a broad theme. Component tokens should remain attached to buttons, cards, or forms. Page-specific values should not be promoted until another page confirms them.

The result is an observed design reference that can guide implementation or a later export. It is not the same as owning the website's official internal design system, especially when source definitions and responsive rules are unavailable.

## Use this in your AI agent

> Inspect the captured website across multiple pages and extract observed design tokens. Group them into typography, colors, surfaces, spacing, borders, radii, shadows, gradients, and component states. For every token, give a semantic role, observed value, where it appears, and confidence. Separate shared tokens from component-specific and page-specific values. Compare pages before marking a value shared, and clearly label anything that cannot be verified from the captures. Return the result as an implementation-ready token worksheet.

[Install Fudge for your AI agent](/mcp)

---

Two pages are enough for an initial comparison, but three gives you a better check when the site has several page types. Choose pages with different content rather than three nearly identical marketing pages. A product page, settings page, and dashboard often reveal more than three landing pages.

Compare the same roles on each page: background, surface, primary text, secondary text, border, accent, control radius, and common spacing. Mark a token as shared when the treatment appears in the same functional role across pages. If a color appears on one page as a button fill and on another as a selected state, it may be a shared accent, but record the different uses.

Do not require every page to use every token. Some roles are conditional. An error color may appear only on a form page, while a modal surface may appear only in an interaction state. The important distinction is between repeated evidence and a value that appears once. Keep the latter as a candidate until more evidence is available.

---

Use a format that keeps the semantic role, observed value, and usage together. A simple table or JSON object works well for review. For each token, include a stable name, value, category, usage notes, source page, and confidence.

A practical structure looks like this:

```json
{
  "color": {
    "surfacePage": {
      "value": "observed color",
      "usage": "full page background",
      "confidence": "high"
    }
  },
  "radius": {
    "control": {
      "value": "observed radius",
      "usage": "buttons and fields",
      "confidence": "medium"
    }
  }
}
```

Keep raw observations in a notes column or nearby source field. That makes it easier to revise a token when a later page disagrees. Separate global roles from component roles, and include responsive or state differences when they are visible. If you export the notes into code, treat the generated values as a starting point for implementation and test them against the original captures at the same viewport sizes.

## Related questions

- [Extract a Website's Gradient Styles](/share/extract-a-website-s-gradient-styles)
- [Extract a Website's Interaction Patterns](/share/extract-a-website-s-interaction-patterns)
- [Extract a Website's Complete Design System](/share/extract-a-website-s-complete-design-system)
- [Extract a Website's Page Layout](/share/extract-a-website-s-page-layout)