# Export a Website Design System as CSS Custom Properties

[Open the live Fudge conversation](https://design.withfudge.com/share/export-a-website-design-system-as-css-custom-properties)

Last updated: 2026-08-25

To export a website design system as CSS custom properties, collect the visible colors, typography, spacing, borders, radii, shadows, and repeated component patterns. Then map those observations to semantic variables that your own project can use. Treat the result as an observed reference export, not as proof of the source site's official internal design system.

## Start with the values that repeat

Do not turn every measured pixel into a variable. Begin with values that repeat or describe a clear role:

- Page background, surfaces, borders, primary text, muted text, and accent colors
- Font families, available weights, approximate sizes, and line heights
- Repeated spacing between sections, cards, controls, and text groups
- Common border widths, corner radii, shadows, and control heights
- Shared patterns for buttons, inputs, cards, navigation items, and badges

Use names such as `--color-text-primary` and `--radius-control` instead of names that only describe a raw color or one page location. Keep the original observation beside each semantic assignment so you can revise the role later.

The captured Linear example below is paired with a typography result using Inter at weights 400 and 500. Use it as a grounded example of how a reference can inform an export, not as a universal token set.

## 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.

## Create an editable CSS file

Use a small semantic layer, then let components consume it:

```css
:root {
  --color-page-background: #0b0b0d;
  --color-surface: #151518;
  --color-text-primary: #f5f5f5;
  --color-text-muted: #a3a3a8;
  --color-border-subtle: #2a2a30;
  --color-accent: #7c5cff;

  --font-family-body: "Inter", sans-serif;
  --font-weight-regular: 400;
  --font-weight-medium: 500;
  --font-size-body: 1rem;
  --line-height-body: 1.5;

  --space-xs: 0.5rem;
  --space-sm: 1rem;
  --space-md: 1.5rem;
  --space-lg: 2rem;
  --space-xl: 4rem;

  --radius-control: 0.5rem;
  --radius-card: 0.75rem;
  --shadow-card: 0 12px 32px rgb(0 0 0 / 0.18);
}

.button {
  min-height: 2.75rem;
  padding-inline: var(--space-sm);
  border-radius: var(--radius-control);
  color: var(--color-text-primary);
}
```

The sample values above show the shape of an export. Replace them with values supported by the reference, and remove categories that were not observed. Create component variables only when a pattern repeats. A one-off hero treatment belongs in a component note unless it establishes a broader rule. If the reference shows both light and dark states, keep their values in separate theme scopes rather than silently choosing one.

## Keep evidence beside every value

CSS is convenient but loses context. Keep a companion JSON record or comments for source, role, and confidence:

```json
{
  "color-text-primary": {
    "value": "#f5f5f5",
    "role": "hero heading and primary copy",
    "source": "captured hero state",
    "confidence": "observed"
  },
  "space-section": {
    "value": "64px",
    "role": "repeated section separation",
    "source": "single desktop viewport",
    "confidence": "estimated"
  }
}
```

Use `observed` when the capture directly supports a value, `estimated` when you measured a visual relationship, and `unverified` when a placeholder still needs checking. Include responsive, hover, focus, and dark-mode values only when those states were actually observed. If a state is a project decision, label it as such.

Before sharing the file, check that every variable has a role, every unit is explicit, font weights are available, repeated spacing is grouped sensibly, and components use variables instead of duplicated values. Compare the rendered result against the reference at the same viewport, then review the generated diff. Also check text wrapping, contrast, control dimensions, and fallback fonts. Those checks often reveal that a token is close numerically but wrong in practical use.

## Use this in your AI agent

> Inspect the supplied website reference and export a CSS custom property file from supported observed details. Use semantic names for colors, typography, spacing, borders, radii, shadows, and repeated component values. Keep a companion record of source context, confidence, estimates, and limitations. Include only states that were actually observed, validate the CSS, and clearly label the result as an observed reference export rather than the website's official internal design system. Use the captured examples below to guide the visual comparison.
>
> [Install Fudge for your AI agent](/mcp)

---

Start with the smallest set that explains repeated choices: page background, surface, primary text, muted text, border, accent, body font, heading weight, body size, line height, two or three spacing steps, one or two radii, and one shadow. Add control height and focus styling only when those patterns are visible.

Use semantic roles rather than raw color names:

```css
:root {
  --color-page-background: #111214;
  --color-surface: #1a1b1f;
  --color-text-primary: #f4f4f5;
  --color-text-muted: #a1a1aa;
  --color-border: #303039;
  --color-accent: #7c5cff;
  --font-family-body: "Inter", sans-serif;
  --font-weight-body: 400;
  --font-weight-emphasis: 500;
  --space-page: 1.5rem;
  --space-section: 4rem;
  --radius-control: 0.5rem;
  --radius-card: 0.75rem;
}
```

Replace the sample values with supported observations. Keep one-off treatments in component CSS and record uncertain values beside the export instead of presenting them as established facts. Then test the variables on a heading, paragraph, button, card, and input. If a token does not improve consistency across at least two uses, keep it local until more evidence appears.

---

Separate what the reference proves from what your project still needs to decide. A single desktop capture can support visible colors, type roles, radii, and spacing, but it may not establish mobile gutters, hover behavior, focus rings, or breakpoint changes.

Organize the file so later states can be added without changing component code:

```css
:root {
  --layout-page-gutter: 2rem;
  --layout-content-max: 72rem;
  --control-focus-ring: 0 0 0 3px rgb(124 92 255 / 0.35);
}

@media (max-width: 48rem) {
  :root {
    --layout-page-gutter: 1rem;
  }
}
```

Mark the mobile value as a project decision if it was not visible in the reference. Document the selector and interaction that still needs checking. Review text, icons, borders, controls, and focus indicators in every observed theme and state. For each new breakpoint, compare wrapping and spacing in a browser at the target width, and keep a short change note so later edits do not turn an assumption into a claimed observation.

## Related questions

- [Export a website design system as CSS variables](/share/export-a-website-design-system-as-css-variables)
- [Export a website design system as color and font tokens](/share/export-a-website-design-system-as-color-and-font-tokens)
- [Create a Tailwind v4 Theme from a Website Reference](/share/create-tailwind-v4-theme-from-a-website-reference)
- [Create structured JSON design details from a website reference](/share/create-structured-json-design-details-from-a-website-reference)