Generate CSS Variables From a Live Website

Use a live page as the reference, then turn observations into tokens

To generate CSS variables from a live website, start with a captured page, identify its repeated visual values, and map those values into named roles rather than copying isolated colors. A useful first draft should cover colors, typography, spacing, borders, radii, shadows, and gradients, with every variable tied to a visible use such as page background, primary text, button fill, or card border.

Use this workflow:

1. Capture the page at the viewport you want to reproduce.
2. Inspect the main sections, navigation, buttons, cards, forms, and responsive states.
3. Record repeated values and group them by role.
4. Export a CSS draft.
5. Check the draft against the page and rename or merge tokens before using it in a product.

The key decision is whether a value is a reusable design choice or a one-off detail. A page may contain many slightly different grays, but your CSS file should usually distinguish roles such as --color-text-muted and --color-border-subtle, not create a new variable for every sampled pixel.

Open the examples below and compare the first screen before borrowing a pattern. The captured Linear reference is paired with a typography example showing Inter at weights 400 and 500, with body copy, labels, navigation, headings, and emphasized interface text separated by use.

A practical CSS variable structure

A small token draft can look like this:

Treat these values as a working draft, not as an official internal design system. A live page shows the rendered result, but it may not reveal the original source names, design decisions, component states, or values used elsewhere in the product. Keep a short note beside uncertain tokens and verify them across more than one section.

Checks that improve the result

Before adopting the variables, run four checks:

• Repeated use: Does the value appear in several components, or only once?
• Role clarity: Would another developer know when to use the variable?
• State coverage: Are hover, focus, disabled, dark, and error states represented where visible?
• Responsive behavior: Do spacing and type values still make sense at smaller widths?

Typography deserves special attention. Check the family, available files, weights, sizes, and line heights separately. A heading that looks heavier may use a different weight, a larger size, tighter tracking, or simply a darker color. Do not collapse those observations into one vague heading token.

Turn the draft into a usable handoff

A strong CSS export includes a short usage note for each non-obvious variable. For example, --color-surface may be used for cards and menus, while --color-page belongs to the overall canvas. Include the source page, capture viewport, date of inspection, and any values that still need confirmation. Then compare the generated tokens against real components rather than reviewing the variable list alone.

If you are recreating the page, export only the observed details you can support. If you are building a broader product system, use the draft as evidence for a starting point and then define the system deliberately with your own naming, accessibility checks, and state rules.

Use this in your AI agent

> Inspect the captured website reference and generate a CSS variables draft. Group repeated colors, typography, spacing, borders, radii, shadows, and gradients by practical UI roles. Include the observed font families and weights, show which page elements use each token, flag uncertain values, and finish with a concise verification checklist. Do not present the result as the website's official design system. > > Install Fudge for your AI agent

Use names based on purpose, not appearance. Prefer --color-text-muted over --gray-500, --color-action over --blue, and --space-section over --large-gap. Role names survive a palette change and tell the next person where the value belongs.

Keep the first layer small. A useful starting set is page, surface, text, muted text, border, action, success, warning, and danger. For spacing, use a consistent scale such as --space-1 through --space-8, then add semantic aliases such as --space-card-padding only when a component relationship matters. Do the same for type: define a family and weight scale, then add aliases for body, label, heading, and display text.

If two sampled values look nearly identical, merge them unless they serve clearly different states. If one value appears only in a single illustration or decorative effect, leave it local instead of promoting it to a global token. This keeps the generated CSS readable and makes later review faster.

First, compare the variables against the page at the same viewport and zoom. Check the largest visual decisions: page background, text contrast, primary action, card surfaces, heading scale, section spacing, and border treatment. Then test common states such as keyboard focus, hover, disabled controls, validation errors, and dark mode if the reference shows them.

Next, confirm the font files and weights instead of relying on a visual guess. Check that the chosen weights exist, that line height remains readable at smaller sizes, and that fallback fonts do not change wrapping unexpectedly. Measure contrast for text and controls with your normal accessibility checker.

Finally, separate observed facts from project decisions. The page may suggest a spacing scale or color role, but your project still needs naming rules, component states, responsive behavior, and ownership. Keep the source reference and a short uncertainty list with the draft. That makes the file useful without treating a visual inspection as complete documentation.

Related questions

• Generate a DESIGN.md File from a Live Website
• Generate CSS Custom Properties from a Live Website
• Generate color and font tokens from a live website
• Export a Website Design System as a Tailwind v4 Theme