# Convert Website Design Details into Color and Font Tokens

[Open the live Fudge conversation](https://design.withfudge.com/share/convert-website-design-details-into-color-and-font-tokens)

Last updated: 2026-08-25

To convert website design details into color and font tokens, first separate observed values by role, then name each token by how it is used rather than by where it appeared. A useful token set should help you rebuild the visual hierarchy without repeatedly guessing at colors, font weights, or spacing.

## Start with roles, not raw values

Create two inventories: one for color and one for type. For color, record roles such as:

- `color.background.canvas`
- `color.background.surface`
- `color.text.primary`
- `color.text.muted`
- `color.border.subtle`
- `color.action.primary`
- `color.status.success`
- `color.status.danger`

If a page uses several shades of the same color, keep the raw values in a scale as well, such as `color.neutral.50` through `color.neutral.900`. Role names make tokens useful across a project. A value called `blue-700` describes hue and intensity; `text.primary` describes when to use it.

For typography, record the family, weight, size, line height, and letter spacing wherever those details are available. A practical starting set is:

- `font.family.sans`
- `font.family.display`
- `font.family.mono`
- `font.size.body`
- `font.size.label`
- `font.size.heading`
- `font.weight.regular`
- `font.weight.medium`
- `font.weight.semibold`
- `font.lineHeight.body`
- `font.lineHeight.heading`

The captured Linear references show how a compact type system can use Inter for interface text, with Berkeley Mono and Tiempos Headline appearing as supporting choices in one captured typography set. Treat those names as evidence from the supplied capture, not as a general recommendation for every project.

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

## Build a token table

Use a table that preserves both the observation and the implementation name:

| Role | Token | Observed value | Use |
|---|---|---|---|
| Canvas background | `--color-background-canvas` | `#...` | Page background |
| Primary text | `--color-text-primary` | `#...` | Main copy and headings |
| Muted text | `--color-text-muted` | `#...` | Supporting copy and metadata |
| Body family | `--font-family-sans` | Inter | Body, labels, controls |
| Heading weight | `--font-weight-heading` | 500 | Headings and emphasis |

Keep an `observed` value separate from a `chosen` value when you normalize the system. For example, two nearly identical grays can become one shared muted token, but record that it was consolidated. This keeps the result honest and makes later review easier.

## Check contrast and hierarchy

Token conversion is not just copying values into a file. Check whether the proposed roles preserve the page's hierarchy. Primary text should remain stronger than muted text. Borders should support grouping without competing with copy. Action colors should remain recognizable when used for buttons, links, and focus states.

For type, compare relative steps rather than only font names. Ask whether headings are larger, heavier, tighter, or more widely spaced than body copy. One family can still feel distinctive when its size and weight relationships are consistent. Adding a display face does not automatically improve hierarchy.

## Choose an output format

Use CSS variables when the tokens will be consumed directly by a browser. Use Tailwind v4 theme values when the project already works in Tailwind. Use JSON when the same values need to move between tools. Use DESIGN.md when the main goal is a readable handoff with explanations and examples.

Whichever format you choose, include a short usage note for every non-obvious token. Explain whether a value was observed directly, grouped from several similar observations, or proposed as a project default. That distinction matters when a reference is inspirational rather than an official internal design system.

A simple final checklist:

1. Every color has a role or scale name.
2. Every font family has a documented purpose.
3. Weight, size, and line height are recorded together.
4. Text and action colors are checked for readable contrast.
5. Similar values are consolidated only with a note.
6. The output format matches the project where it will be used.

## Use this in your AI agent

> Inspect the captured website design details, identify color roles and typography families, weights, sizes, and line heights, then convert the observations into named CSS and Tailwind v4 tokens. Separate directly observed values from normalized or proposed values, include a compact token table, and flag any contrast or hierarchy decisions that need human review. Use roles such as canvas background, surface, primary text, muted text, border, action, body type, heading type, and monospace type. Compare the captured examples before choosing the final naming scheme.

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

---

Use role names for common decisions and numbered scales for reusable ranges. For example, keep `text.primary`, `text.secondary`, and `text.muted` for semantic use, then keep `neutral.50` through `neutral.900` when components need a broader palette.

For similar grays, compare where each one appears. A gray used for body copy should not automatically become the same token as a gray used for borders. If the visual difference is too small to matter in the rebuilt interface, consolidate the values and record that choice as normalization rather than observation.

For fonts, name weights by function when possible: `font.weight.body`, `font.weight.label`, and `font.weight.heading`. If the same family is used at several weights, also retain numeric aliases such as `400`, `500`, and `600`. This gives designers readable names while preserving implementation flexibility.

Avoid names such as `gray-blue-final` or `font-2`. They describe the capture, not the design decision. A good test is whether another page in the same project could use the token without knowing which website inspired it.

---

Include a short summary, the token file, and a usage table. The summary should state which details were directly observed and which were grouped or proposed. The token file should use the naming convention already present in the project, such as CSS custom properties or a Tailwind theme block.

For each color, include the role, value, and a one-line usage note. For each font, include the family name, fallback stack, available weights, and the roles where it appears. Add size and line-height pairs for body copy, labels, headings, and any display treatment that materially changes the hierarchy.

Also include a review list: missing font files, uncertain weights, close colors that were consolidated, and contrast checks that should be confirmed in the final implementation. This prevents a token export from being mistaken for ownership of the reference site's private design system. It is an observed, reusable starting point that still needs project-level decisions.

## Related questions

- [Convert Website Design Details into CSS Custom Properties](/share/convert-website-design-details-into-css-custom-properties)
- [Convert a Website into a Tailwind v4 Theme for AI Coding Agents](/share/website-to-tailwind-v4-theme-converter-for-ai-coding-agents)
- [Convert Website Design Details into JSON Design Tokens](/share/convert-website-design-details-into-json-design-tokens)
- [Website to JSON Design Tokens Converter for AI Coding Agents](/share/website-to-json-design-tokens-converter-for-ai-coding-agents)