Generate structured JSON design details from a live website

To generate structured JSON design details from a live website, separate what you observed from what you recommend, then give the observations a stable schema. Capture the public page, record its URL and viewport, inspect its visible typography and components, and export only details that the capture supports. The result is a practical design reference for implementation, not the site's private specification.

Define the source and scope first

The first fields should explain where the data came from and what it covers. Include the page name, URL, capture date if useful, viewport, page state, and scope. If you inspected only the landing page, say so. Do not imply that a single page represents every route, breakpoint, or logged-in state.

A compact starting shape is:

Treat these names as your working schema. They are not facts about the source site's own naming.

Store details developers can use

For colors, record semantic role, value, frequency when available, contrast context, and source location. A secondary text role is more useful than a long list of sampled grays. For typography, keep family, observed variant, weight, approximate size, line height, tracking, casing, and usage separate. The supplied Linear reference supports Inter at weight 400 for body copy, labels, navigation, and controls, and weight 500 for headings and emphasized interface text. Treat that as evidence from the captured reference, not a universal rule for every Linear page.

For layout, record the content width, column behavior, section spacing, card padding, grid gap, alignment, border radius, border treatment, shadow, gradient, and responsive behavior when visible. For components, use stable entries such as button, card, input, and navigation. Add default, hover, focus, disabled, active, or expanded states only when those states were inspected.

Keep page-specific details close to their source. If a hero has a special overlay or illustration crop, store it under that page or component rather than promoting it to a global theme value. Mark estimates and unresolved details clearly.

Validate and prepare the handoff

Use a short review checklist before exporting:

1. Confirm the URL, viewport, and page state.
2. Separate exact observations, estimates, and recommendations.
3. Check whether a font file and variant were observed or only a rendered family name.
4. Keep responsive values under a breakpoint or viewport key.
5. Do not claim hidden tokens, source files, private usage rules, or ownership.
6. Parse the JSON and require consistent units.
7. Add confidence, notes, or open questions where evidence is limited.

If the goal is Tailwind, CSS, or a developer handoff, keep this JSON as the neutral source and generate implementation files afterward. That makes corrections easier when another page shows a different heading size, color role, or component state. A small set of named, traceable details is more useful than a large file filled with guesses.

Fudge lets you inspect a saved website capture's page structure, typography, colors, spacing, components, and responsive details, then export supported observations into JSON, CSS, Tailwind v4, or DESIGN.md. Use Fudge with your AI agent when the agent needs to inspect and organize the reference rather than rely on a screenshot alone.

Use this in your AI agent

> Inspect the captured website reference and return a structured JSON design reference containing source scope, colors, typography families and weights, spacing, borders, radii, shadows, gradients, component states, page structure, responsive notes, and confidence values. Preserve source locations where useful. Clearly label estimates and recommendations, keep page-specific patterns separate from repeated values, and do not claim to reproduce the site's private internal design system. > > Use Fudge with your AI agent.

Use fields that map cleanly to CSS variables and Tailwind theme values, while keeping source observations separate from generated implementation. A practical theme section is:

Add line heights, background images, and breakpoints when the capture supports them. Use semantic names such as surface, text-muted, and accent instead of names tied to one component. Keep component-specific exceptions under components. If a value is estimated, add a note rather than silently turning it into an exact-looking token.

Give the handoff three layers: the source record, normalized tokens, and implementation examples. The source record should name the page, URL, capture scope, viewport, and limits. The normalized section should contain the values developers are expected to reuse. The examples section can show a primary button, card, heading, and form field using those tokens.

Add a verification checklist: confirm the font loads, compare the main heading and body copy at the recorded sizes, check light and dark surfaces, test focus and disabled states, and test the narrowest recorded viewport. Mark details as observed, estimated, or unverified.

If several pages were inspected, preserve each page under sources and create a consensus section only for values that recur. Keep one-off patterns attached to their page. This gives developers a useful starting point without turning a screenshot-based approximation into an official specification.

Related questions

• Generate a Tailwind CSS theme from a live website
• Generate a Reusable Design Reference File from a Live Website
• Generate JSON design tokens from a live website
• Website to Color and Font Tokens Converter for AI Coding Agents