Export a website design system as CSS variables

Exporting a website design system as CSS variables means turning observed colors, typography, spacing, borders, shadows, and repeated component patterns into reusable custom properties. The safest workflow separates what you can see from the names and structure you choose for your own project. The result describes observed design details; it does not prove the source site's official internal system.

Build the variable map first

Start with a short inventory before writing CSS:

• Background, surface, raised-surface, border, text, muted-text, accent, success, warning, and danger colors
• Font families, available weights, approximate sizes, and line heights
• Spacing between sections, cards, controls, and text groups
• Border widths, corner radii, shadows, and common control heights
• Repeated patterns such as buttons, inputs, navigation items, cards, and badges

Use semantic names in the final file. Prefer --color-text-muted over --gray-500 when the value has a clear interface role. Keep raw observations separate from semantic assignments so a role can change without renaming every component.

The Linear reference below is paired with a compact typography example: Inter at weight 400 for body and control text, and weight 500 for headings and emphasized interface text. Treat those details as an observed reference, not a universal rule for every website.

Use a structure that stays editable

A practical starting shape is:

The values above show a file shape, not verified values for a particular site. Replace them with checked observations. If the reference has a dark mode, override the same semantic names instead of duplicating component rules:

Check states and evidence

Compare the generated variables against the source in four passes. First, check hierarchy: headings, body copy, labels, and muted text should have clear differences in size, weight, or color. Second, check spacing: repeated gaps should use a small set of steps rather than dozens of one-off values. Third, check components: buttons, cards, and fields should use semantic roles rather than hard-coded colors. Fourth, check states: hover, focus, disabled, selected, and error styles should be included only when they were observed or clearly marked as project decisions.

Keep a companion JSON or DESIGN.md record with the value, role, source viewport or state, and confidence. Mark estimates rather than turning them into facts. Check text contrast in its real surface context, confirm that font names and weights are available to your project, and compare the CSS-rendered result against the reference before committing it.

For multiple pages, compare repeated patterns before choosing shared variables. For a single page, do not imply that one capture reveals responsive behavior or every component state. The more important the handoff, the more useful it is to list open questions beside the export.

A website inspection workflow can help you review page structure, typography, color roles, spacing, borders, radii, shadows, and component styles before creating CSS. It can also export supported observed details into CSS, Tailwind, JSON, or DESIGN.md, so choose the format that matches the next step in your project.

Use this in your AI agent

> Inspect the saved website reference and export its observed design details as a maintainable CSS variables file. Group variables by semantic color roles, typography, spacing, borders, radii, shadows, and component states. Separate directly observed values from inferred names, flag uncertain details, and include a short usage example for buttons, cards, inputs, and page surfaces. Compare repeated patterns across pages when available. Do not claim the export is the site's official internal design system. > > Install Fudge for your AI agent

Use semantic variables so component code stays unchanged while theme values change. Define roles such as --color-page, --color-surface, --color-text, --color-text-muted, --color-border, and --color-accent in the default theme, then override those names in a dark theme selector.

Avoid naming theme-facing variables only by hue or lightness, such as --gray-700, because the same gray may serve different roles in different modes. If raw values are useful, keep them in a separate reference section and map them into semantic roles.

Check contrast for body text, muted text, icons, borders, controls, and focus indicators in both modes. Review interactive states separately. A dark theme often needs different surface separation, border visibility, and shadow treatment rather than simply inverting every color. Mark values inferred from screenshots or page samples and verify them against additional states before treating them as final.

Give it the website reference, the target CSS file location, and the parts of the page you want included. Ask for a semantic token map first, then the CSS output, then a small component example that proves the variables are usable.

Specify the required groups: colors and states, font families and weights, type sizes and line heights, spacing, radii, borders, shadows, and repeated component styles. Ask the agent to include source notes for each observed value and to label anything estimated. If you have multiple pages, ask it to compare them before choosing shared values.

You can use this compact instruction:

> Review these website references and create tokens.css with semantic CSS custom properties for colors, typography, spacing, borders, radii, shadows, and component states. Compare repeated patterns across pages, preserve observed values, label estimates, and add examples for a button, card, input, and dark theme. Keep the result editable and do not present it as the original team's official design system.

Related questions

• Export a website design system as a DESIGN.md file
• Create a Tailwind v4 Theme from a Website Reference
• Export Website Design Details as Structured JSON
• Create a reusable design reference file from a website