# Convert website design details into CSS variables

[Open the live Fudge conversation](https://design.withfudge.com/share/convert-website-design-details-into-css-variables)

Last updated: 2026-08-25

To convert website design details into CSS variables, inventory repeated visual roles and map each role to a reusable name. Then validate the variables against real components instead of treating a screenshot or captured page as a complete official design system.

## Use semantic variables first

Begin with values that control the widest range of the interface:

```css
:root {
  --bg-page: #ffffff;
  --bg-panel: #f7f7f8;
  --text-strong: #171717;
  --text-soft: #6b6b72;
  --line-subtle: #e5e5e7;
  --brand: #5e6ad2;

  --type-body: "Inter", system-ui, sans-serif;
  --type-display: "Inter", system-ui, sans-serif;
  --size-body: 1rem;
  --size-small: 0.875rem;
  --size-display: clamp(2rem, 5vw, 4.5rem);
  --leading-body: 1.5;

  --gap-xs: 0.25rem;
  --gap-sm: 0.5rem;
  --gap-md: 1rem;
  --gap-lg: 1.5rem;
  --gap-xl: 2rem;

  --corner-sm: 0.375rem;
  --corner-md: 0.625rem;
  --corner-lg: 1rem;
  --elevation-low: 0 1px 3px rgb(0 0 0 / 0.08);
}
```

These names are a starting point. Choose one naming style and use it consistently. A role-based name such as `--text-soft` explains use better than `--header-gray`, which becomes misleading when the value appears elsewhere.

The examples use the captured Linear page and the supplied typography observation: Inter at weight 400 for body copy, labels, navigation, and controls, with weight 500 for headings and emphasized interface text. Treat that as reference evidence for this example, not as a universal rule for another project.

## Captured pages

[![The system for product development](https://pin.fontofweb.com/6434?format=jpg)](https://design.withfudge.com/share/pin-6434)

[The system for product development](https://design.withfudge.com/share/pin-6434)

## Linear typography

- **Inter** — weight 400 · Body copy, labels, navigation, and controls.
- **Inter** — weight 500 · Headings and emphasized interface text.

## Build an observation inventory

Record each detail before writing the final CSS:

| Area | Detail | Variable candidate | Confidence |
| --- | --- | --- | --- |
| Page | Main background | `--bg-page` | High if repeated |
| Copy | Secondary text | `--text-soft` | Medium if sampled visually |
| Type | Body family and weight | `--type-body` | High when the variant is identified |
| Cards | Border and radius | `--line-subtle`, `--corner-md` | Medium until checked across cards |
| Layout | Repeated gaps | `--gap-md`, `--gap-lg` | Medium until measured in several sections |
| Effects | Shadow softness | `--elevation-low` | Low to medium from a screenshot |

This makes the conversion easier to audit and reduces one-off variables. Promote a value when it repeats or expresses a clear design role. Keep directly observed values separate from decisions made for your new project.

## Connect variables to components

Use the variables in component rules so changes propagate:

```css
.card {
  background: var(--bg-panel);
  border: 1px solid var(--line-subtle);
  border-radius: var(--corner-lg);
  box-shadow: var(--elevation-low);
  padding: var(--gap-lg);
}

.button {
  background: var(--brand);
  border-radius: var(--corner-md);
  color: var(--bg-page);
  font: 500 var(--size-small) / 1.2 var(--type-body);
  padding: var(--gap-sm) var(--gap-md);
}
```

A captured action color does not prove that it is the source site's official brand token. An identified family does not establish every size, line height, or responsive rule. Record those as separate decisions unless stronger evidence confirms them.

## Validate before production use

Test long and short labels, large headings, muted copy, cards, buttons, focus states, and narrow screens. Check text wrapping after loading the intended font. Compare repeated components rather than relying on one prominent section. Review contrast for strong and muted text, borders, and actions. Confirm that radii and shadows work across the surfaces where they will appear.

A useful final file includes a comment or companion table for uncertain tokens. Treat the result as a project starter, not a guaranteed copy of private rules. If confidence matters, inspect more pages and states, compare repeated components, and update the table before expanding the variable set.

## Use this in your AI agent

> Review the saved website reference and extract observed colors, font families and variants, type sizes, line heights, spacing, borders, radii, shadows, and component styles. Convert repeated roles into a maintainable CSS variables file using semantic names. Include a token table with value, use, confidence, and source. Separate observed details from claims about an official internal design system. Show how the variables apply to a card and button, then give a production validation checklist.

[Install Fudge for your AI agent](/mcp)

---

Use semantic names for variables that components consume, and add a small raw scale when it helps maintain the theme. For example, keep `--gray-100` and `--blue-500` as source values, then map them to `--bg-panel`, `--text-soft`, or `--brand`.

```css
:root {
  --gray-100: #f7f7f8;
  --gray-700: #6b6b72;
  --blue-500: #5e6ad2;

  --bg-panel: var(--gray-100);
  --text-soft: var(--gray-700);
  --brand: var(--blue-500);
}
```

The scale shows the palette while the semantic layer explains use. Avoid names like `--purple-button` if the value may later serve links, badges, or focus rings. Do not create a large scale from one page. Add values when repetition, contrast, or a deliberate component role makes them useful.

---

Apply the variables to three representative pieces: a page shell, a card, and an action control. Use realistic content and test wide and narrow layouts. This exposes missing roles for hierarchy, spacing, borders, and responsive behavior.

Then review the following:

1. Load the intended font files and confirm the selected weights exist.
2. Test long headings and labels for wrapping and overflow.
3. Check primary and muted text against their backgrounds.
4. Compare repeated cards and controls for consistent radius and spacing.
5. Add focus, hover, disabled, and error roles if the project needs them.
6. Mark estimated values so they can be replaced without confusion.

Treat the result as a project starter, not a guaranteed copy of the source site's private rules. For higher confidence, inspect more pages and states, compare repeated components, and update the table before expanding the variable set.

## Related questions

- [Convert Website Design Details into a design.md File](/share/convert-website-design-details-into-design-md-file)
- [Convert a Website into a Tailwind v4 Theme for AI Coding Agents](/share/website-to-tailwind-v4-theme-converter-for-ai-coding-agents)
- [Convert Website Design Details into CSS Custom Properties](/share/convert-website-design-details-into-css-custom-properties)
- [Convert Website Design Details into a Design Report](/share/convert-website-design-details-into-design-report)