Export Website Design Details as Structured JSON

Build a reviewable JSON record of a website's observed colors, fonts, spacing, components, and visual rules for design or frontend work.

export a website design system as structured json design details

To export website design details as structured JSON, inspect the captured page in layers, record the values you can actually observe, and organize them by reusable roles. The result should help a designer or frontend developer compare patterns and make implementation decisions without claiming to be the site's complete or official design system.

Use an evidence-first structure

Separate source scope, raw observations, semantic roles, and component usage. This keeps a useful detail from disappearing when someone gives it a new implementation name.

Each observation should say what the value is, where it appears, and whether the interpretation is directly visible or inferred. A color record can identify the heading, navigation, card, or button where it was found instead of presenting an unexplained list of hex codes.

Captured pages

Linear typography

  • Inter

    Weight 400

  • Inter

    Weight 500

Inspect the page in a repeatable order

Start with the viewport and page sections. List the header, navigation, hero, content blocks, cards, forms, footer, and repeated controls. Then inspect each layer:

  • Typography: family, file or variant when available, weight, size, line height, letter spacing, and casing.
  • Color: backgrounds, surfaces, text roles, borders, accents, status colors, gradients, and contrast relationships.
  • Layout: container width, columns, alignment, gaps, padding, and responsive changes.
  • Shape and depth: border width, radius, shadow, blur, and elevation patterns.
  • Components: button states, cards, inputs, navigation items, overlays, and repeated combinations.

The supplied Linear reference is a concrete comparison point. It uses Inter at weight 400 for body copy, labels, navigation, and controls, and Inter at weight 500 for headings and emphasized interface text. Document that as a reference observation, not a universal rule.

Preserve raw details and useful roles

Keep raw fields such as fontFamily: Inter, weight: 400, and usedIn: body copy. Add a semantic role such as type.body without replacing the raw record. Do the same for repeated surface colors or spacing values. If a role is inferred from repetition rather than named by the site, say so in a note.

A component can reference tokens instead of duplicating values:

This makes the file easier to review, compare, and convert into CSS, Tailwind, or documentation.

Check scope before sharing

A captured page cannot establish every route, interaction, breakpoint, hidden state, or unavailable font variant. Label the scope clearly. Use unknown or a note when a detail was not available instead of guessing. Verify that repeated elements use consistent names, values include units, colors preserve their roles, and component references resolve to real tokens. Compare the JSON with the page one more time before handing it to a team.

Use this in your AI agent

> Inspect the captured website and create a structured JSON record of its observed design details. Organize the output into source scope, raw observations, semantic roles, typography, colors, spacing, borders, radii, shadows, gradients, layout patterns, and repeated components. Include where each value appears, distinguish observed values from inferred roles, mark unavailable details as unknown, and avoid claiming that the result is the site's official internal design system.

Use Fudge with your AI agent to make this inspection repeatable.

What fields should I add to each design detail?

Use fields that answer four questions: what is the value, where does it appear, how certain is the interpretation, and how might another person use it?

For fonts, add family, variant, weight, size, line height, and letter spacing. For colors, add format, role, contrast context, and whether the value is solid or part of a gradient. For components, reference shared tokens and list visible states. Keep status simple: observed, repeated, inferred, or unknown.

How can I make the JSON useful for comparing two websites?

Use the same category names and role vocabulary for both records, then compare the semantic layer rather than only raw values. For example, compare color.surface, type.body, space.section, radius.card, and component.button.primary across both files.

Keep the comparison separate from the original observations:

Compare equivalent elements at the same scope, such as two hero sections or two card grids. Record whether each difference is visible, measured, or inferred. This prevents a missing mobile state or unavailable font variant from being mistaken for a genuine product difference.