# Generate color and font tokens from a live website

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

Last updated: 2026-08-25

To generate color and font tokens from a live website, capture a representative page, identify how each value is used, and export semantic roles instead of copying isolated samples. A useful token set explains that a color is a surface, border, link, or muted label and that a font is used for body copy, headings, code, or display text.

## Build the token set in three passes

**Pass one: typography.** Record every visible family, then connect it to its use. Capture weight, size, line height, letter spacing, and casing where they affect the result. A page may use one family for most interface text and additional families for code or editorial headings. The example below shows a captured Linear reference with Inter Variable, Berkeley Mono, and Tiempos Headline. Treat those as observed examples from that reference, not as a universal rule for every Linear page.

**Pass two: color roles.** Group colors by what they do: page background, elevated surface, primary text, muted text, border, accent, link, success, warning, and danger. Record frequency and nearby contrast when available. A color that appears often in a large surface should not be given the same role name as a color used only for a small icon.

**Pass three: repeated structure.** Look for spacing, radii, borders, shadows, gradients, and component patterns that recur across the page. Tokens become more useful when they describe a system of relationships, such as a compact spacing scale or a consistent radius family, instead of a long list of measurements with no context.

Open the examples below and compare the font roles before turning them into project tokens. The captured notes distinguish primary sans-serif text, supporting monospace text, and an editorial display face, which is more useful than a single answer to "what font is this?"

## Captured pages

[![Linear typography](https://pin.fontofweb.com/4902?format=jpg)](https://design.withfudge.com/share/pin-4902)

[Linear typography](https://design.withfudge.com/share/pin-4902)

## Fonts captured on linear.app

- **Inter Variable** — weight 400 · Primary sans serif in the captured Linear typography system.
- **Berkeley Mono** — Supporting monospace typeface in the captured system.
- **Tiempos Headline** — An occasional editorial display face in the captured system.

## Use semantic names

A token file should help a person choose the right value later. Prefer names such as:

```json
{
  "color": {
    "background": "...",
    "surface": "...",
    "text": "...",
    "textMuted": "...",
    "border": "...",
    "accent": "..."
  },
  "font": {
    "body": "...",
    "heading": "...",
    "mono": "...",
    "display": "..."
  }
}
```

The values above are placeholders for the captured observations. Do not fill them by guessing or by copying a nearby color that serves a different purpose. If the page does not reveal a status color or a mobile heading size, leave that token unverified and list it as an open question.

## Make tokens implementable

For a first pass, create a small core set instead of exporting every visible variation. A practical color set includes background, surface, elevated surface, text, muted text, border, accent, and link. Add status roles only when they are visible. For typography, define body, heading, label, code, and display roles only when the capture supports them.

Then add metadata for each token: source reference, observed usage, weight or size, confidence, and notes about where it appears. This prevents a developer from treating a page-specific sample as an official site-wide value. It also makes later comparisons easier when you capture another page.

If the project uses Tailwind v4, export named theme values that can be used in utility classes. If it uses custom properties, export CSS variables. Choose JSON when tokens will feed another tool, and DESIGN.md when people need the reasoning alongside the values. Choose one output format first, then keep names aligned across formats so a designer and developer are discussing the same roles.

## Check the result on a test screen

Before adopting the tokens, make a small page with a heading, body paragraph, muted label, primary button, card, border, and code sample if a monospace role was observed. Check whether the type hierarchy still works when the text changes, whether muted text remains readable, and whether surfaces and borders remain distinct without relying on color alone.

Also check the font files and variants, not just the family name. A variable family may support a range of weights, while a captured page may show only one visible weight. Record what was observed and avoid claiming that every variant is available unless you have verified it. A token set is most reliable when it communicates both reusable values and the limits of what the page showed.

## Use this in your AI agent

> Inspect the captured website and generate semantic color and font tokens. Identify font families, visible variants, weights, sizes, line heights, and usage roles. Group colors by role, include frequency and contrast notes where supported, and record spacing, borders, radii, shadows, gradients, and repeated component styles. Mark observations separately from assumptions and leave unseen states unverified. Export matching Tailwind v4, CSS, JSON, and DESIGN.md versions with consistent token names.

[Install Fudge for your AI agent](/mcp) to turn this into a repeatable reference workflow.

---

Create the smallest set that explains the visible design. For color, start with background, surface, text, muted text, border, accent, and link if those roles are clearly present. Add elevated surface or status colors only when the page shows a distinct use. If two colors look similar but serve different jobs, keep both roles and document the difference.

For fonts, define body, heading, label, mono, or display only when the capture supports those uses. Record the visible weight and size for each role. Do not create tokens for every tiny shade or every possible font variant. Too many tokens make future choices harder and encourage inconsistent usage.

You can add detail after testing the starter set on a small screen. If a new component needs a value that does not fit an existing role, first check whether the reference shows a real repeated pattern. Otherwise, add it as a local component value rather than presenting it as a global rule.

---

Use them as observed design references, then adapt them to your own product. Keep source notes beside each group of tokens, distinguish page-level observations from repeated patterns, and avoid presenting the result as the source site's official internal system. This is especially important when you have only one capture.

Test the tokens with your own content and components. Check text contrast, focus states, hover and disabled states, responsive wrapping, long labels, and data-heavy screens. A color that looks balanced in a marketing hero may not work for a form border or dense table. A display font that suits a large headline may not work for labels.

Finally, rename roles around your product's needs. `accent` or `surface` is more useful than a source-specific name such as `purple-500`. Keep a short note showing where the value came from, but let the implementation describe how your team should use it.

## Related questions

- [Generate CSS Custom Properties from a Live Website](/share/generate-css-custom-properties-from-a-live-website)
- [Export a Website Design System as a Tailwind v4 Theme](/share/export-a-website-design-system-as-tailwind-v4-theme)
- [Generate a DESIGN.md File from a Live Website](/share/generate-design-md-file-from-a-live-website)
- [Export Website Design Details as Structured JSON](/share/export-a-website-design-system-as-structured-json-design-details)