Generate JSON design tokens from a live website

Create a traceable JSON token draft from a website capture, covering colors, type, spacing, shapes, components, and confidence.

generate json design tokens from a live website

To generate JSON design tokens from a live website, capture the page you want to study, inspect repeated visual decisions, and organize those observations into semantic roles. The result should be a traceable draft for implementation, not a claim that you discovered the site's private source files or official token names.

Begin with a scoped capture

Record the URL, viewport, page state, and pages included in the review. A home page, pricing page, and authenticated dashboard may use different surfaces and component states, so do not merge them without noting the scope. If you are studying a responsive system, capture at least one wide and one narrow viewport.

Start with repeated decisions rather than isolated pixels. Look for the background used across sections, the main text color, muted text, borders, buttons, repeated gaps, card shapes, and common type styles. Give every value a role and a location, such as color.textMuted on secondary navigation labels or radius.card on repeated content cards.

Captured pages

Linear typography

  • Inter

    Weight 400

  • Inter

    Weight 500

Use a role-based JSON schema

A useful draft can include meta, color, font, space, border, radius, shadow, component, responsive, notes, and openQuestions. Each token can carry a value, confidence, source page, and source element. For example:

Use high confidence for values repeated across clearly visible elements, medium for a likely pattern supported by a few examples, and low for an estimate or one-off treatment. Keep an empty value out of the token set when you cannot verify it. Put the uncertainty in openQuestions instead.

Check the details before handoff

Inspect page structure before deciding that a value is global. A dark hero may be a section surface rather than the page background. A bright button may be a primary action, an active state, or a temporary campaign treatment. For typography, keep family, file or variant when observed, size, weight, line height, tracking, and casing as separate fields. For spacing, compare repeated distances between headings, paragraphs, cards, and sections instead of recording every measurement.

Describe borders and shadows as complete treatments, including width, color, blur, spread, and offset when visible. Record component states only when they were actually inspected. Keep gradients, image crops, overlays, and responsive changes attached to the relevant page or component when they are not repeated.

Before using the draft in code, normalize units and choose names that fit your project. It is often safer to keep the observed reference JSON separate from an approved project theme. Validate contrast, focus states, text wrapping, and behavior at narrow widths. If a later capture disagrees, update the observation and preserve the reason for the change.

A captured website can provide material for JSON, CSS, Tailwind v4, or DESIGN.md. Fudge lets you inspect saved website captures and organize observed details for that handoff. Use Fudge with your AI agent when you want the agent to inspect the reference and produce a traceable draft.

Use this in your AI agent

> Inspect the supplied live website capture and generate a JSON design-token draft. Group only verified or clearly repeated observations into semantic roles for colors, typography, spacing, borders, radii, shadows, gradients, components, and responsive behavior. Include the source URL, viewport, scope, confidence for each value, and source element or page where useful. Keep one-off styles separate, distinguish observations from recommendations, and include open questions. Do not claim that the output is the website's official internal design system. > > Use Fudge with your AI agent.

Which design tokens should I extract first from a live website?

Start with the decisions that recur across the most visible parts of the page:

  1. Typography: family, body and heading weights, common sizes, line heights, tracking, and casing.
  2. Surfaces and text: page background, raised surface, primary text, muted text, border, and accent roles.
  3. Layout: content width, section spacing, card padding, grid gaps, and repeated alignment rules.
  4. Shape: button and card radii, border widths, and repeated shadow treatments.
  5. Components: buttons, cards, navigation items, inputs, badges, and visible states.

Then review gradients, image crops, overlays, and responsive changes. Keep those details local to a section unless the same treatment appears elsewhere. Add a confidence value and source note beside every token so a second page can confirm or replace it.

How do I turn observed JSON tokens into safe CSS variables?

Keep the observed JSON as the source record and create a separate approved layer for your project. Map roles to variables instead of copying page-specific names:

Normalize units, document fallbacks, and test the variables in real components. Check text contrast, keyboard focus, hover and disabled states, wrapping at narrow widths, and behavior when content grows. If a value was approximate, label it provisional instead of hiding uncertainty in the stylesheet. This keeps an observed visual reference separate from a maintained project theme.

Related questions