Export a Website Design System as JSON Design Tokens

To export a website design system as JSON design tokens, inspect the captured page first, record what is actually visible, and then organize those observations into reusable roles. A page can reveal valuable design patterns, but it may not show every route, breakpoint, interaction, or internal rule. Treat the file as an evidence-based design record rather than proof of the site's complete official system.

Start with a practical token structure

Use predictable groups so the result can be reviewed or converted later:

Keep unknown values as unknown instead of filling them with guesses. Include a source note for each value so another person can check it against the page.

Inspect before assigning roles

Check the viewport and page structure first. List the header, navigation, hero, content sections, cards, forms, footer, and repeated controls. Then inspect the details used by those elements. Record font family, available variants, weight, size, line height, letter spacing, and casing. For colors, record the value, role, and where it appears. For layout, note repeated gaps, container widths, alignment, and padding. Also inspect border widths, radii, shadows, gradients, and visible component states.

The supplied Linear reference gives a concrete example: Inter at weight 400 is used for body copy, labels, navigation, and controls, while weight 500 is used for headings and emphasized interface text. Preserve that as an observed reference, not as a recommendation for every website.

Separate observations from implementation names

A useful export has three layers:

1. Observed details: the value and where it appears.
2. Semantic roles: names such as color.text.muted or space.section.
3. Component references: links from buttons, cards, inputs, and navigation to those roles.

If several values are similar but not identical, keep them separate until you know whether the difference represents a state, gradient, component, or rendering effect. Do not turn every one-off pixel measurement into a global token. Add a status field such as observed, repeated, inferred, or unknown, and keep the raw observation available when a role name is later challenged.

Validate the file before sharing

Check that values have units, font weights are available, repeated components use consistent names, and component references resolve. Compare the JSON with every captured viewport you have. Mark unavailable hover states, mobile layouts, font variants, or interaction details as unknown. Check that colors are valid, numeric values have predictable types, and arrays are used consistently for multi-value properties such as shadows or font stacks. Export the reviewed result as JSON, then decide which tokens are stable enough for production use.

A practical review pass should also render the tokens on representative headings, body text, buttons, cards, and form controls. Compare those results with the captured page at the same viewport. Keep tokens that explain repeated decisions, and leave isolated offsets or uncertain states attached to the relevant component until more evidence is available.

Use this in your AI agent

> Inspect the captured website and export its observed design details as structured JSON design tokens. Include semantic color roles, typography families and variants, spacing, borders, radii, shadows, gradients, and repeated component styles. Keep raw observations separate from inferred token names, mark unknown values clearly, and include a source note for every token. Do not claim this is the site's official internal design system. Compare the result against the captured page before finalizing it. > > Use Fudge with your AI agent to run this workflow from your agent.

Use stable top-level groups such as meta, colors, typography, spacing, borders, radii, shadows, gradients, and components. Store value, role, source, status, and usedBy where useful. A color might look like this:

Keep component entries separate from global tokens. A primary button can reference color.accent, radius.sm, and typography.label without copying their values. Use statuses such as observed, repeated, inferred, and unknown so implementation decisions remain visible. For a team, also include a stable token identifier, an optional description, and a clear type such as color, dimension, font family, or shadow. Keep numeric dimensions as numbers with an explicit unit, or adopt one consistent representation throughout the file. That makes validation and later conversion much easier.

Review the file first and remove values that only describe one isolated screen. Then map stable semantic roles to CSS custom properties:

For Tailwind, place the same roles in the theme format supported by your Tailwind v4 setup. Test the tokens on headings, body copy, buttons, cards, and form controls. Keep one-off offsets as component rules unless they recur elsewhere, and compare the rendered result with the captured reference before replacing local styles. Preserve the JSON as the review record, because generated CSS or Tailwind configuration may omit source notes and uncertainty labels. If a token is still inferred, keep that status visible in the implementation review rather than presenting it as a measured fact.

Related questions

• Export a website design system as a reusable design reference file
• Export Website Design Details as Structured JSON
• Export a Website Design System as a Tailwind CSS Theme
• Export a Website Design System as CSS Custom Properties