# Convert Website Design Details into Structured JSON

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

Last updated: 2026-08-25

To convert website design details into structured JSON, define a consistent document shape first, then place each observation under a role that explains how it is used. The result should preserve page context while remaining practical for design and development work.

## Use a schema that mirrors the design

A useful structure separates shared values from layout and component observations:

```json
{
  "meta": {
    "source": "website reference",
    "status": "observed",
    "viewport": "1440px",
    "notes": []
  },
  "colors": {},
  "typography": {},
  "layout": {},
  "spacing": {},
  "borders": {},
  "shadows": {},
  "components": {}
}
```

This is easier to review than one flat list because related details remain together. For example, `typography.body` can contain family, weight, size, line height, letter spacing, and usage instead of scattering those properties across unrelated entries.

The captured Linear reference and typography summary show how evidence can be attached to a structured document. The supplied summary identifies Inter at weights 400 and 500 for different interface roles. Use that information as a reference for the captured example, not as a complete specification for every page.

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

## Give every value a clear role

Use names such as `pageBackground`, `cardRadius`, `bodyFont`, and `sectionGap` when they describe a concrete job. Do not infer a role from a value alone. A dark gray could be text, a border, a surface, or an overlay, so record the observed use and add an uncertainty note when needed.

```json
{
  "typography": {
    "body": {
      "family": "Inter",
      "weight": 400,
      "size": "16px",
      "lineHeight": 1.5,
      "usage": "body copy, labels, navigation, and controls"
    },
    "heading": {
      "family": "Inter",
      "weight": 500,
      "size": "32px",
      "lineHeight": 1.15,
      "usage": "headings and emphasized interface text"
    }
  },
  "colors": {
    "pageBackground": { "value": "#101012", "usage": "main page background" },
    "surface": { "value": "#18181b", "usage": "cards and panels" },
    "mutedText": { "value": "#99999f", "usage": "secondary copy" }
  }
}
```

If the same value appears in several roles, keep one shared base value and list its uses. If similar values perform different jobs, keep them separate even when they look close.

## Organize layout and components

Put page-level measurements in `layout` and `spacing`: content width, page padding, section gap, grid gap, card padding, control height, and alignment rules. Use `borders` for width, style, color, and radius. Use `shadows` for offset, blur, spread, color, and opacity when those properties can be observed.

Component entries should describe reusable patterns rather than every individual element. A button can include label typography, height, horizontal padding, radius, background, text color, border, and observed states. A card can include surface, padding, radius, border, shadow, and title spacing.

For missing evidence, be explicit:

```json
{
  "components": {
    "primaryButton": {
      "background": "{colors.accent}",
      "radius": "{borders.radiusMedium}",
      "states": {
        "default": { "status": "observed" },
        "hover": { "status": "not observed" }
      }
    }
  }
}
```

This keeps an unreviewed state visible instead of filling it with a guess.

## Check the JSON before sharing it

Confirm that the document parses, naming uses one convention, units are consistent, repeated values are defined once, and every reference resolves. Record source context, viewport, and page state in `meta`. Mark details as `observed`, `inferred`, `recommended`, or `unverified`, and review representative components before calling the document a shared system.

Structured JSON should preserve decisions as well as values. If a second page changes your conclusion, update the status and review notes rather than rewriting the original observation.

## Use this in your AI agent

> Convert the supplied website design details into structured, valid JSON. Use sections for metadata, colors, typography, layout, spacing, borders, shadows, and reusable components. Give every value a role-based name, preserve units, include usage notes and source context, and label details as observed, inferred, recommended, or unverified. Use references for repeated values, check that references resolve, and return one clean JSON document.

[Install Fudge for your AI agent](/mcp) to repeat this structured review workflow whenever you add another website reference.

---

Structured JSON design details are the broader record. They can include page sections, component observations, viewport context, usage notes, source references, and uncertainty. Design tokens are the reusable values inside that record, such as a color, font style, spacing step, radius, or shadow.

For example, this is a token:

```json
{ "value": "16px", "role": "standard card padding" }
```

This is a structured component detail that uses the token:

```json
{
  "card": {
    "padding": "{spacing.md}",
    "surface": "{colors.surface}",
    "radius": "{radii.card}",
    "source": "pricing page reference"
  }
}
```

Keep both layers when possible. The token layer supports implementation and reuse. The broader detail layer preserves why a value exists, where it was observed, and whether it has been approved. This matters when you are studying one public page rather than documenting a confirmed internal system.

---

Use this compact template as a starting point:

```json
{
  "meta": {
    "source": "",
    "viewport": "",
    "status": "observed",
    "notes": []
  },
  "colors": {
    "pageBackground": { "value": "", "usage": "" },
    "surface": { "value": "", "usage": "" },
    "primaryText": { "value": "", "usage": "" },
    "mutedText": { "value": "", "usage": "" },
    "accent": { "value": "", "usage": "" }
  },
  "typography": {
    "body": { "family": "", "weight": 400, "size": "", "lineHeight": "" },
    "heading": { "family": "", "weight": 500, "size": "", "lineHeight": "" }
  },
  "spacing": {},
  "radii": {},
  "borders": {},
  "shadows": {},
  "components": {}
}
```

Fill only what the page supports. Use an empty object for a category you have not reviewed, and add a note rather than guessing. After the first pass, validate the JSON, normalize naming, and replace repeated raw values with references to shared tokens.

## Related questions

- [Convert Website Design Details into a Tailwind CSS Theme](/share/convert-website-design-details-into-tailwind-css-theme)
- [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 JSON Design Tokens](/share/convert-website-design-details-into-json-design-tokens)
- [Create color and font tokens from a website reference](/share/create-color-and-font-tokens-from-a-website-reference)