Export a website design system as color and font tokens

To export a website design system as color and font tokens, inspect the captured page, assign each observed value a useful role, and export only details you can support. The result should explain how typography and color are used, rather than claiming to reproduce the site's complete internal system.

Build tokens around roles

Start with semantic roles that a new interface can use immediately.

Color tokens

• background: the main page canvas
• surface: cards, panels, or raised areas
• foreground: primary headings and body text
• muted: secondary descriptions, labels, and less prominent text
• border: dividers, outlines, and control edges
• accent: primary actions, links, or highlighted states
• success, warning, and danger: only when those states are visible

Font tokens

• font.body: the main reading and interface family
• font.heading: the family or weight used for prominent headings
• font.label: controls, navigation, and compact interface text
• font.mono: code or technical content, if observed
• font.display: editorial or occasional display text, if observed

The examples below show a captured Linear typography reference with Inter Variable as the primary sans serif, Berkeley Mono as supporting monospace, and Tiempos Headline as an occasional editorial face. Treat these as observations from that reference, not as a universal recipe.

Record context with every token

A token is useful when it includes a value, role, visible location, and status. For example:

Use the same approach for fonts:

Replace #CHECKED_VALUE only after checking the captured page. Record whether a color appears frequently or only in one component. A bright accent used for links and buttons should not automatically become the background for every callout.

Pick the implementation format

Choose the format based on who will use the export:

Keep a readable reference beside the implementation output. The reference explains why muted exists and where it appears. The token file provides a value developers can use. Update both when a later review changes a role.

Check the export before reuse

Use this checklist:

• Every color has a role and a visible use.
• Every font has a family, weight or variant when known, and usage note.
• Text and background choices are checked together for readable contrast.
• Display, body, label, and monospace roles are not mixed without a reason.
• Unseen hover, focus, mobile, and error states are marked unverified.
• Repeated values are grouped into tokens instead of duplicated component values.
• The export labels values as observed or proposed where appropriate.

A family can appear in a capture without revealing every file, weight, fallback, or licensing detail needed by a production project. Confirm the variant and usage before adding it to a shipped build.

A reference may also contain shades created by images, gradients, antialiasing, or one-off illustrations. Export interface colors first and keep decorative colors in a separate section. This makes the token set easier to maintain and reduces accidental overuse of a distinctive accent.

Use this in your AI agent

> Inspect the captured website reference and export observed typography and color details as semantic tokens. Include font families, variants, weights, sizes, line heights, and roles; include colors grouped by background, surface, text, muted text, border, accent, status, and gradient use. Return a readable DESIGN.md section and implementation-ready JSON, CSS, or Tailwind v4 tokens. Clearly separate observed values from recommendations and mark unseen states as unverified.

Install Fudge for your AI agent

For fonts, include a semantic role, family name, variant or file when known, weight, size, line height, letter spacing, and usage note. Common roles include body, heading, label, mono, and display, but create a role only when the reference supports it.

For colors, include a semantic role, value, visible location, and status. Useful roles include background, surface, foreground, muted, border, accent, success, warning, danger, and gradient. Add frequency or priority only when you have a reliable observation, and keep decorative or image-derived colors separate from interface tokens.

Optional fields such as source, notes, and verified help distinguish a checked value from a proposed adaptation. Note whether a font appears in body copy, headings, navigation, controls, or editorial content. Note whether a color is used for text, fill, border, icon, or interaction. Do not force every observed shade into a global token.

Review the tokens in a small test screen before using them throughout the project. Combine the body font, heading treatment, muted text, accent button, card surface, border, and one status state. This exposes weak hierarchy, crowded spacing, or an accent that is too strong outside its original context.

Check contrast between text and its actual background, including muted labels and controls. Confirm that the font variant you plan to ship is represented in the reference. If the capture does not show focus, hover, disabled, mobile, or error states, leave those states as design decisions instead of inventing them from the export.

Keep raw observations and adapted tokens separate. A new product may need a softer accent, different content width, or fallback font even when it borrows the same visual direction. Label those changes as adaptations. Finally, have a developer consume the chosen format without copying raw values into components. If they need to guess what a token means, improve the role and note first.

Related questions

• Export a Website Design System as CSS Custom Properties
• Create a Tailwind v4 Theme from a Website Reference
• Create structured JSON design details from a website reference
• Create a reusable design reference file from a website