Create color and font tokens from a website reference

Create practical color and font tokens from a captured website, with clear roles, usage notes, and checks that keep the result reusable.

create color and font tokens from a website reference

Contents

  • [Start with roles, not swatches](#start-with-roles-not-swatches)
  • [Build a font token set](#build-a-font-token-set)
  • [Connect tokens to components](#connect-tokens-to-components)
  • [Validate the token set](#validate-the-token-set)
  • [Use this in your AI agent](#use-this-in-your-ai-agent)

To create color and font tokens from a website reference, first assign every observed value a job, then record where that value appears and how confident you are in reusing it. A useful token set is smaller than a screenshot inventory: it gives your team names for repeated decisions while keeping one-off treatments and unknown states separate.

Start with roles, not swatches

Do not begin with a flat list of hex codes. Begin with roles that a product can use:

  • background: the main page canvas
  • surface: cards, panels, or raised areas
  • surface-muted: quieter sections or controls
  • text: primary readable content
  • text-muted: supporting labels and secondary copy
  • border: dividers and control edges
  • accent: links, calls to action, or selected states
  • success, warning, and danger: status feedback when observed

For each color, record the value, location, frequency or recurrence, and whether it appears in a specific state. A color used once in an illustration should not automatically become a global token. A color repeated across navigation, buttons, and links is a stronger candidate for a shared role.

The examples below include a captured Linear reference and typography observations. Use them to compare how a font list becomes a usage map, rather than treating the cards as proof of every color or state on the product.

Captured pages

Fonts captured on linear.app

Build a font token set

A font token needs more than a family name. Record the family, variant or file when available, weight, style, size, line height, tracking, and role. A practical set might look like this:

Do not fill an unobserved field with a default and present it as fact. Mark it as needing review, or define it as a project choice outside the reference. The captured Linear typography example identifies Inter Variable as a primary sans serif, with Berkeley Mono and Tiempos Headline as supporting choices. That is enough to create provisional roles for comparison, but not enough to claim that every page or component uses each face.

If a family appears in multiple weights, keep the family token separate from the weight tokens. This makes it easier to change the family later without rewriting every component. If the source uses variable fonts, record the variable range or the observed weights so the implementation does not accidentally flatten the system.

Connect tokens to components

Tokens become useful when each one has examples. Map color and font roles to buttons, links, cards, navigation, forms, headings, body copy, code, and status messages. For example, a button might use surface-accent, text-on-accent, a medium interface weight, a fixed radius, and a defined hover state. A card might use surface, border, body text, muted text, and a shadow or no shadow.

Keep component decisions separate from global values. A card can use the surface token but still have its own padding and radius. A heading can use the heading family but have different size tokens at different breakpoints. This separation lets your team reuse the visual language without copying every dimension from one page.

Validate the token set

Run four checks before sharing the tokens:

  1. Role check: can a teammate understand each name without seeing the original page?
  2. Repeat check: does the value appear often enough to justify a token?
  3. Contrast check: do text and controls remain readable against their recorded surfaces?
  4. State check: are hover, focus, disabled, dark, and error values recorded or clearly marked unknown?

Then use the set in one small screen and compare it with the reference. Look for accidental overuse of accent color, weak muted text, headings that lose hierarchy, and a monospace or display face applied outside its observed role. Revise the names before adding more tokens. A compact, well-labelled set is easier to maintain than dozens of precise but unexplained values.

Use this in your AI agent

> Inspect the captured website reference and create a reusable token set for colors and typography. Group colors by observed role, record values and locations, identify font families, variants, weights, sizes, line heights, and usage, separate observations from project choices, flag unknown states, and return consistent CSS, JSON, or Tailwind v4 token names with a short validation checklist.

Install Fudge for your AI agent.

How many color tokens should a website reference usually have?

Use as few color tokens as the repeated interface decisions require. A good starting point is one token for the page background, one or two surfaces, primary and muted text, borders, one accent, and only the status colors that the reference actually shows.

A practical starting set

For a light interface, begin with background, surface, surface-muted, text, text-muted, border, and accent. Add text-on-accent if buttons or selected controls need a reliable foreground color. Add success, warning, and danger only when those states are present or your product clearly needs them.

Do not create separate tokens for every slight shade unless the difference has a repeated job. Instead, note a one-off illustration color or decorative gradient as a component value. This keeps the global palette understandable.

After the first pass, compare the same roles across several sections. If two shades serve the same job, merge them or label the distinction. If one token is used for unrelated jobs, split it. The right count is the smallest set that preserves hierarchy, states, and readability without forcing unrelated components to look identical.

How can I check that font tokens match the reference before implementation?

Check font tokens against both appearance and usage. A family name alone is not enough because weight, size, line height, tracking, and fallback behavior can change the result.

Use a comparison sheet

Create a small sheet with the same sample text in each proposed role: navigation, body copy, heading, button label, metadata, and code if relevant. Show the observed family and weight beside the proposed token. Compare letter shapes, density, x-height, line breaks, and the amount of space each block occupies.

Then check the files or variants available to the project. Confirm that the requested weights exist and that the fallback stack does not silently replace the intended face. If the reference uses a variable family, test the actual weights rather than assuming regular and bold are sufficient.

Finally, apply the tokens to one representative page section. Review heading hierarchy, paragraph length, button labels, and narrow layouts. If text wraps very differently, adjust the project size or line-height choice and record that as an implementation decision, not as an observed fact. Keep the reference values and your adapted values visibly separate so future reviewers know what changed.

Related questions