# Convert Website Design Details into JSON Design Tokens

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

Last updated: 2026-08-25

You can convert website design details into JSON design tokens by first recording the visible design decisions, then mapping each one to a stable token name and value. Keep the result organized by colors, typography, spacing, borders, shadows, and component patterns so it can move cleanly into code or documentation.

## Start with a token inventory

Begin with the parts of the website that affect repeated decisions rather than collecting every isolated value. Record the page background, main text, muted text, accent colors, borders, focus states, heading styles, body styles, spacing steps, corner radii, shadows, and common control states. If a value appears once and has no clear role, keep it as an observation rather than promoting it to a reusable token.

Use role-based names instead of names tied to one page. For example, `color.background.canvas` is more useful than `color.homepage.gray`, and `text.heading.lg` is more useful than `font.hero.title`. A practical inventory can include `color.text.primary`, `color.text.muted`, `color.border.subtle`, `space.4`, `radius.md`, `shadow.card`, and `type.body.fontFamily`.

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

## Build JSON that is easy to use

A useful token file separates raw values from meaning. For example:

```json
{
  "color": {
    "background": { "canvas": "#0f1014", "surface": "#17191f" },
    "text": { "primary": "#f5f7fa", "muted": "#9da3ae" },
    "accent": { "primary": "#8b5cf6" },
    "border": { "subtle": "#2a2d36" }
  },
  "type": {
    "body": { "fontFamily": "Inter", "fontSize": "1rem", "lineHeight": 1.5, "fontWeight": 400 },
    "heading": { "fontFamily": "Inter", "fontSize": "3rem", "lineHeight": 1.05, "fontWeight": 500 }
  },
  "space": { "1": "0.25rem", "2": "0.5rem", "4": "1rem", "8": "2rem" },
  "radius": { "sm": "0.375rem", "md": "0.75rem" }
}
```

The exact values above are only a format example. Replace them with values you have actually observed and label uncertain values clearly. If the site uses several shades of one color, keep both the shade and its role when possible. That lets a developer reuse the palette without losing the contrast relationship between a surface, its border, and its text.

The captured examples below show a compact sans-serif approach: Inter at weight 400 for body copy, labels, navigation, and controls, and Inter at weight 500 for headings and emphasized interface text. Treat that as an example to compare, not as a universal answer for every website.

## Check the tokens before handing them off

Test the file against a small set of real components: a page shell, a heading and paragraph, a button, an input, a card, and a navigation item. Check whether the names explain their purpose, whether repeated values are actually shared, and whether states such as hover, focus, disabled, and selected have a place. Also check that text and borders remain readable against their assigned surfaces. A design-detail export is useful when someone can apply it without reopening the original page for every decision.

Separate observed details from interpretation. A JSON file can contain a `meta` section with the source page, capture date if known, viewport if known, and notes such as `observed`, `inferred`, or `needsReview`. Do not present an inferred breakpoint, spacing scale, or component state as an official internal design-system rule. When the goal is implementation, validate the tokens in the target framework and remove values that do not support a repeated decision.

A reliable handoff checklist is: every token has a meaningful name, every color has a role, typography includes family, size, weight, and line height, spacing follows a consistent unit, components reference tokens instead of hard-coded copies, and uncertain values are marked for review. Then compare the first screen and one dense interaction area against the source before expanding the set.

## Use this in your AI agent

> Inspect the saved website reference and convert only the observed, reusable design details into JSON design tokens. Group the output into colors, typography, spacing, borders, radii, shadows, and component states. Use role-based names, include values and useful notes, distinguish observed values from inferences, and return a clean JSON object plus a short review checklist. Do not invent an official design system or unsupported responsive rules. Open the examples below and compare the first screen before borrowing any pattern.
>
> [Install Fudge for your AI agent](/mcp)

---

Use a structure that separates shared categories from component-specific decisions. Keep colors, type, spacing, radii, borders, and shadows at the top level, then let components refer to those values by role.

```json
{
  "color": {
    "background": { "canvas": "...", "surface": "..." },
    "text": { "primary": "...", "muted": "..." },
    "action": { "primary": "...", "primaryHover": "..." },
    "border": { "subtle": "...", "strong": "..." }
  },
  "type": {
    "body": { "family": "...", "size": "...", "weight": 400, "lineHeight": "..." },
    "headingLg": { "family": "...", "size": "...", "weight": 500, "lineHeight": "..." }
  },
  "space": { "1": "...", "2": "...", "4": "...", "8": "..." },
  "radius": { "sm": "...", "md": "..." },
  "component": {
    "button": { "background": "{color.action.primary}", "radius": "{radius.md}", "paddingX": "{space.4}" }
  }
}
```

Use references only if your consuming tool supports them. Otherwise, resolve the values during a build step. Keep a small `meta` object for source and review notes, and mark inferred values so they are not mistaken for confirmed rules.

Copyable prompt: [Use Fudge with your AI agent](/mcp) to inspect the saved reference and return a role-based JSON token file with observed and inferred values separated.

---

First decide whether the JSON is your source file or only an export. If it is the source, generate CSS variables and framework values from it so the names stay consistent. Map role names to variables such as `--color-text-primary`, `--space-4`, and `--radius-md`, then use those variables in components.

For CSS, keep the generated layer readable:

```css
:root {
  --color-background-canvas: #0f1014;
  --color-text-primary: #f5f7fa;
  --color-text-muted: #9da3ae;
  --space-4: 1rem;
  --radius-md: 0.75rem;
}
```

For Tailwind, map the same roles into the theme rather than renaming them casually. Test the generated values on a page shell, text pair, button, card, and form control. Compare those components with the captured reference at the same viewport, then adjust only values that are visibly wrong or lack a clear role. Keep the JSON, generated CSS, and any Tailwind configuration in the same review so a later change does not update one representation while leaving another behind.

Copyable prompt: [Use Fudge with your AI agent](/mcp) to inspect the reference, export observed values to JSON, and map the result to CSS variables or Tailwind theme values without inventing unsupported rules.

## Related questions

- [Convert website design details into a reusable design reference file](/share/convert-website-design-details-into-reusable-design-reference-file)
- [Convert Website Design Details into Structured JSON](/share/convert-website-design-details-into-structured-json-design-details)
- [Convert Website Design Details into a Tailwind CSS Theme](/share/convert-website-design-details-into-tailwind-css-theme)
- [Create color and font tokens from a website reference](/share/create-color-and-font-tokens-from-a-website-reference)