Generate CSS Custom Properties from a Live Website
Create a reviewable set of CSS custom properties from observed website typography, colors, spacing, surfaces, and component styles.
generate css custom properties from a live website
You can generate CSS custom properties from a live website by inspecting repeated visual details, naming those details by role, and testing the variables on your own components. The safest result is an observed reference layer that you can adapt, not a claim that you recovered the site's complete official design system.
Start with a token inventory
Check the live page in this order:
- Page structure: note the main background, content width, section spacing, navigation, hero, cards, forms, and footer.
- Typography: identify font families, available files or variants, sizes, weights, line heights, casing, tracking, and the difference between headings, body copy, labels, and controls.
- Colors: group values by role, including background, surface, primary text, muted text, border, accent, and state colors where they are visible.
- Shape and depth: record repeated radius, border, shadow, gradient, and overlay treatments.
- Responsive behavior: check what changes when the viewport narrows, especially type size, columns, padding, navigation, and card layout.
The examples below give you a concrete reference to compare. The captured Linear page is identified as “The system for product development,” and the typography example records Inter at weights 400 and 500 for body, labels, navigation, controls, headings, and emphasized interface text. Use those details as an example of how to document an observation, not as a complete list of variables for every page.
Captured pages
Linear typography
- Inter
Weight 400
- Inter
Weight 500
Name variables by purpose
Avoid names such as --blue-1 or --gray-4 unless your project truly needs raw scales. Prefer names such as:
Fill the values only after confirming where they repeat. If a color appears once in an illustration, keep it as a local value rather than promoting it to a global variable. If a font family or weight is observed but the file is not available to your project, document that gap instead of silently substituting a different font.
Check the generated CSS
Use a simple verification page with a background, surface, heading, paragraph, muted label, button, card, and input. Confirm that the variables produce a coherent hierarchy when combined, not just that each swatch resembles the reference.
Check contrast for text and controls on every surface where they appear. Test long content, focus or active states if visible, narrow widths, and a second page section. A variable can look correct in one screenshot but be too faint, too bright, or too tight in another context.
Also separate what the page shows from what you infer. A live page may expose only one state of a component. You may not know its hover, error, loading, disabled, or dark-mode rules from that view. Add a comment such as /* observed on reference page */ and keep inferred extensions in a separate section.
Turn the inventory into a working system
Keep the first export small. Start with the variables that support the page's main surfaces, type hierarchy, spacing rhythm, and repeated components. Once those work, add component-specific variables such as button height, card padding, input radius, or navigation gap.
This approach makes the CSS useful immediately while preserving a clear boundary between inspection and design decisions. If you need framework support later, the same semantic variables can feed Tailwind v4, component styles, or a documented design handoff.
Use this in your AI agent
> Inspect the live website reference and generate a CSS custom-property inventory for its observed colors, typography, spacing, surfaces, borders, radii, shadows, gradients, and repeated components. Use semantic role names, mark uncertain or inferred values separately, and return a compact :root block plus a checklist for contrast, responsive behavior, and missing component states.
How do I avoid turning one page's colors into bad global CSS variables?
Promote a value to a global variable only when it repeats or clearly serves a shared role. A page background, primary text color, border treatment, or recurring surface is a good candidate. A color used once in an illustration, one decorative gradient, or a single campaign banner should stay local until you see it repeated elsewhere.
For similar neutrals, compare their use rather than forcing them into a scale. Two grays may look close but serve different jobs, such as body text and borders. Name them by role first, then decide whether your project needs a larger scale.
Keep an evidence note beside each variable: where it appeared, which component used it, and whether the value was directly observed or inferred. When you inspect another page, either confirm the role or create a more specific variable. This keeps the generated CSS reviewable instead of making a single screenshot dictate the entire product.
What CSS custom properties should I create first for a new project?
Begin with the smallest set that supports a real page: background, surface, foreground, muted text, border, accent, body font, heading font if different, two or three text sizes, two line heights, two radius values, one or two shadows, and a short spacing rhythm.
Then build a test screen with a heading, paragraph, button, card, input, and responsive section. Add a token only when a repeated difference is visible or a component needs an intentional choice. For example, a separate card radius is useful when cards consistently differ from buttons, but a unique radius for one isolated element may not be.
Before sharing the file, label missing states such as hover, focus, error, disabled, or dark mode rather than guessing them. A clean first layer with known limits is more useful than a large variable list that looks complete but has not been checked across components.