Export a Website Design System as a Tailwind v4 Theme

You can export an observed website design system as a Tailwind v4 theme by checking its typography, colors, spacing, and component patterns, then mapping those findings into semantic theme tokens. Treat the result as a strong implementation starting point, not proof that you have the site's complete internal design system.

Use this workflow

1. Open the reference. Start with the captured page or saved reference you want to study. Check its main page state, viewport, sections, navigation, cards, buttons, and repeated layout patterns.
2. Record the visual building blocks. Collect font families, available weights, sizes, line heights, color roles, spacing steps, borders, radii, shadows, gradients, and recurring component treatments.
3. Separate roles from one-off values. A color used for body text should not automatically become a generic gray-900 token. Label it by its observed role, such as page background, primary text, muted text, accent, border, success, or danger.
4. Map the findings into Tailwind v4 variables. Use readable names that match how your project will use them. Mark uncertain observations for review.
5. Test real components. Apply the tokens to a small page with a heading, paragraph, button, card, form control, and responsive layout. Compare relationships, not just isolated color values.

The captured Linear reference gives the workflow a concrete example. Its supplied typography result shows Inter at weights 400 and 500, with contrast coming from size, weight, and muted color. That is an observed reference, not a universal recommendation.

A practical Tailwind v4 structure

Organize the theme around four layers:

• Color roles: background, foreground, muted foreground, border, accent, accent foreground, and surface.
• Type roles: display, heading, body, label, and small text, with family, weight, size, and line height kept together.
• Shape and depth: radius steps, border widths, and a small shadow scale.
• Layout rhythm: spacing values, container widths, and breakpoint decisions.

For example, define --color-surface once and use it for cards, menus, and other repeated surfaces. If the reference uses several nearly identical neutrals, preserve the relationship only when it helps a real component. A short, coherent token set is easier to maintain than a list of barely different values.

A small Tailwind v4 theme might look like this:

Use actual observed values when the reference supports them. Otherwise, mark the value as a project choice rather than implying that it was measured from the page.

Review before you ship

Create a verification page with a header, navigation item, large heading, paragraph, primary and secondary buttons, card, input, disabled state, and compact mobile layout. Check the same tokens on light and dark surfaces only if the reference shows both.

Compare relationships: heading-to-body contrast, muted text readability, border weight, surface separation, radius consistency, and spacing when content wraps. Test a longer button label, a two-line heading, an error message, and a narrow viewport. If the theme fails under those cases, adjust the role or component rule instead of adding many one-off overrides.

A page inspection can reveal visible design details, but the captured view may not show every state, component, or responsive rule. Validate important tokens against additional pages when consistency matters, and keep a note of what was observed versus what was chosen for your product.

Use this in your AI agent

> Inspect the saved website reference, list its observed typography, color roles, spacing, borders, radii, shadows, and repeated component styles, then export a Tailwind v4 theme with clearly named tokens. Separate directly observed values from implementation choices and include a short verification checklist for headings, body text, buttons, cards, and responsive layouts.

Install Fudge for your AI agent

Start with semantic names that describe each value's job, not names copied from a color picker. A useful first pass might include --color-background, --color-foreground, --color-muted, --color-border, --color-surface, --color-accent, and --color-accent-foreground. Add --color-surface-muted only if the reference clearly uses a second surface level.

For type, keep family and role together: a body family, a heading family if different, and roles such as --font-size-body, --font-size-label, and --font-size-heading. Pair each size with an intentional line height and weight. For spacing, begin with repeated gaps and padding values rather than every measurement visible on one page.

Mark uncertain tokens in comments or documentation. Note where a muted text color was observed and complete a contrast check before using it throughout the product.

Create a small test page with the components most likely to expose inconsistencies: a page header, navigation item, large heading, paragraph, primary and secondary buttons, card, input, disabled state, and compact mobile layout. Check both light and dark surfaces only if the reference shows both.

Compare relationships rather than isolated values. Ask whether heading-to-body contrast feels similar, muted text recedes without disappearing, borders define surfaces without becoming heavy, and spacing survives when content wraps.

Then test content that was not present in the reference: a longer button label, a two-line heading, an error message, and a narrow viewport. If the theme breaks, adjust the token roles or component rules instead of adding many one-off overrides. Keep a short note of what came from observation and what you changed for your own product.

Related questions

• Generate color and font tokens from a live website
• Export a Website Design System as a Tailwind CSS Theme
• Generate CSS Custom Properties from a Live Website
• Export Website Design Details as Structured JSON