# Generate JSON design tokens from a live website

[Open the live Fudge conversation](https://design.withfudge.com/share/generate-json-design-tokens-from-a-live-website)

Last updated: 2026-08-25

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

[![The system for product development](https://pin.fontofweb.com/6434?format=jpg)](https://design.withfudge.com/share/pin-6434)

[The system for product development](https://design.withfudge.com/share/pin-6434)

## Linear typography

- **Inter** — weight 400 · Body copy, labels, navigation, and controls.
- **Inter** — weight 500 · Headings and emphasized interface text.

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

```json
{
  "meta": {
    "source": "https://example.com",
    "viewport": "1440x900",
    "scope": "Public landing page, initial state",
    "status": "observed reference"
  },
  "color": {
    "background": {"value": "#...", "confidence": "high"},
    "textMuted": {"value": "#...", "confidence": "medium"}
  },
  "font": {
    "body": {"family": "Inter", "weight": 400},
    "heading": {"family": "Inter", "weight": 500}
  },
  "notes": [],
  "openQuestions": []
}
```

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](/mcp) 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](/mcp).

---

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.

---

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:

```css
:root {
  --color-background: #...;
  --color-surface: #...;
  --color-text: #...;
  --color-text-muted: #...;
  --color-border: #...;
  --color-accent: #...;
  --font-body: "Inter", sans-serif;
  --font-heading: "Inter", sans-serif;
  --radius-card: ...;
  --space-section: ...;
}
```

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

- [Generate a Reusable Design Reference File from a Live Website](/share/generate-reusable-design-reference-file-from-a-live-website)
- [Generate structured JSON design details from a live website](/share/generate-structured-json-design-details-from-a-live-website)
- [Generate a Tailwind CSS theme from a live website](/share/generate-tailwind-css-theme-from-a-live-website)
- [Generate CSS Custom Properties from a Live Website](/share/generate-css-custom-properties-from-a-live-website)
