To extract a design system from a website, you read its rendered styles off the live page and write them down as reusable tokens: the colors, type scale, spacing rhythm, corner radius, shadows, and component patterns. That beats eyeballing a screenshot and guessing. You can do it by hand with browser devtools, speed it up with extractor tools and AI, then pin the result in a DESIGN.md your coding agent reads on every generation. This guide walks all three paths and where each one earns its keep.
One line to set before you start, because it decides whether this is useful or sketchy: extract the system, not the brand. Pulling a site's spacing logic, type scale, and color roles to inform your own product is what every designer has always done. Lifting its logo, copy, photography, and exact layout and shipping it as yours is theft. Everything below stays on the first side of that line.
What is design system extraction?
Design system extraction is the act of pulling a website's underlying visual rules out of the rendered page and recording them as structured tokens you can reuse. You are not copying the page. You are recovering the decisions behind it: which grays it actually uses, how many font sizes, what the spacing increments are, how round the corners get, how heavy the shadows are. The output is a small set of values plus the rules for using them, not a frozen HTML copy.
This is the "extract the style" job from our clone a website guide, zoomed all the way in. Cloning reproduces that site as code. Extraction harvests that site's system so you can design yours with a real foundation instead of a blank page.
What can you extract from a site?
You can pull six layers, and each one is sitting in the computed styles of the live page. Most "I like that site" feelings come down to a handful of these being consistent.
| Layer | What you are reading | Where it lives |
|---|---|---|
| Color | Primary, neutrals, semantic (success, danger), and where each is used | color, background-color, CSS custom properties |
| Type scale | The actual font sizes, weights, line-heights, and font family | font-size, font-weight, line-height, font-family |
| Spacing | The increment the whole layout snaps to (4px, 8px) | padding, gap, margin |
| Radius | How round cards, inputs, and pills are | border-radius |
| Elevation | Shadow depth and whether they lean on shadows or borders | box-shadow, border |
| Components | The repeating shapes: buttons, cards, nav, inputs | the DOM + the four above, combined |
The trick is to look for the pattern, not every individual value. A good site uses maybe five grays, not forty. If you write down forty, you copied noise. If you write down five, you extracted the system.
How to extract it by hand with devtools
You can extract a design system manually in about fifteen minutes with nothing but the browser inspector. Open the site, right-click the thing you care about, and read its computed styles. This path is free, teaches you the most, and works on any page that renders in a browser.
Extract a design system in devtools
Open devtools and select a real element
Pick the Elements/Inspector panel, then click a real element: a primary button, a card, a heading.
Read the Computed tab, not the source CSS
Computed shows the final resolved value (the actual hex, the actual pixel size) after the cascade and variables. That is the truth you want.
Harvest color first
Note the primary action's background and text, then body text, headings, borders, and muted labels. You will usually find one accent and three to five neutrals. Record what each color is for, not just its value.
Pull the type scale
Inspect each heading level and body text. Record the font-family, the distinct font-size values (you will see a scale like 13, 16, 20, 24, 32), weights, and line-heights.
Find the spacing increment
Inspect paddings and gaps on a few sections. Multiples of 8 mean an 8px grid, multiples of 4 mean a 4px grid. That single number explains most of the rhythm.
Note radius and elevation
Check border-radius on cards, inputs, and pills, and look at box-shadow. Many premium sites use borders and tiny shadows, not big soft blurs. Record both.
Sketch the components
With the four scales in hand, describe the recurring shapes: button height and padding, card border plus radius plus shadow, input style. These are just the tokens recombined.
The honest catch: devtools is manual and slow, and it reads one element at a time. It is perfect for understanding a system, tedious for capturing a whole one. That is where the faster paths come in.
The faster paths: extractor tools and AI
When you want speed over learning, two categories do the harvesting for you: single-purpose extractors and AI agents that read the page. They trade the manual labor of the devtools path for a first draft you refine.
Single-purpose extractors hover over a page and dump CSS. Tools like CSS Scan copy any element's full styles in one click, and font/color inspectors like WhatFont and the browser's own color picker pull type and palette fast. They are great for grabbing raw values, but they hand you every value, so you still do the human part: deciding which five grays are the system and which thirty-five are noise.
The AI path skips the picking. Superdesign's free Chrome "Component Grab" lets you point at any live component, your own production UI or a pattern you admire, and it turns the messy DOM into clean Tailwind pixel perfectly, ready to remix on the canvas or paste into Claude Code or Cursor. Because it reads the real element, the spacing, radius, and states come out real instead of eyeballed from a picture. That is the difference between extracting from reality and extracting from a screenshot, where the model has to guess at everything dynamic.
For the whole-site version, point a context-aware design agent at a live page and it extracts that page's style language (its colors, type, and component patterns) as a foundation you then design new screens on top of, in real React and Tailwind. You are using the reference as a moodboard, not as the final artifact.
Turn the tokens into a DESIGN.md
The extracted tokens are only useful if something reads them on every generation, and that is exactly what a DESIGN.md is for. Once you have your five or six layers written down, drop them into a markdown config your coding agent loads as standing context, so the UI it produces starts on-brand instead of inventing a fresh palette every prompt. Here is what an extracted system looks like once it is structured:
---
# Tokens extracted from a reference site, not copied wholesale.
# These are the system (the rules), restyled for your own brand.
colors:
primary: "#2563EB" # one accent, primary actions only
surface: "#FFFFFF" # page background
text: "#0F172A" # body text
muted: "#64748B" # labels, secondary text
border: "#E2E8F0" # hairline dividers and card edges
typography:
font_family: "Inter, system-ui, sans-serif"
scale: { h1: 32, h2: 24, h3: 20, body: 16, caption: 13 }
weight: { heading: 600, body: 400 }
line_height: { heading: 1.2, body: 1.5 }
spacing:
base: 8 # everything snaps to an 8px grid
scale: [8, 16, 24, 32, 48, 64]
radius: { sm: 6, md: 10, lg: 16, pill: 999 }
elevation:
card: "0 1px 2px rgba(15,23,42,0.06)" # borders over big shadows
---
## Rules
- Use 'primary' once per screen, for the single most important action.
- Body text stays 'text' on 'surface'; never drop below AA contrast.
- Prefer a 1px 'border' to a heavy shadow for separating surfaces.
- Default card radius is 'radius.md' (10px). Do not invent new values.
The YAML pins the exact values so the agent cannot drift on them; the prose carries the judgment the raw numbers cannot. We go deep on the format, where it breaks, and how it relates to CLAUDE.md in what is DESIGN.md. The point for extraction: a screenshot only tells you what one page looked like once, while a written-down token set is reusable input you can build many original screens from.
Where extraction crosses the line
Extracting a site's system to inform your own is fair; reproducing its brand and shipping it is not. The values themselves (a 16px body size, an 8px grid, a blue accent) are not anyone's property; they are common design vocabulary. What is protected is the specific expression: the logo, the written copy, the photography, the exact layout and brand identity.
Fair game
- ✓Recording the spacing rhythm, type scale, and color roles as a starting point
- ✓Grabbing one component pattern and rebuilding it in your own tokens
- ✓Using a site as reference to generate new, original screens
- ✓Extracting your OWN production UI so new pages stay consistent
Crosses the line
- ✕Copying the exact palette, logo, and layout and passing it off as yours
- ✕Lifting their written copy, icons, or photography
- ✕Cloning a competitor's product page pixel-for-pixel
- ✕Shipping an extracted system unchanged as your brand
Keep yourself on the fair side: extract the approach, then restyle it into something that is unmistakably yours. Change the accent, swap the typeface, adjust the rhythm. The system informs your work; it does not become it.
Your extraction workflow
Match the method to your goal, then make the tokens do work. If you want to understand a system, spend fifteen minutes in devtools reading computed styles; you will learn more than any tool teaches you. If you want speed, grab the real component with Component Grab or point a design agent at the page and refine the first draft. Either way, finish by writing the result into a DESIGN.md so your agent generates on-brand by default, and browse the Superdesign prompt library for prompts that pair with those tokens to keep the layout out of generic-AI territory.
Done right, extracting a design system is not copying. It is reading the rules a good site already follows, writing them down as tokens, then spending your real effort on screens those tokens make easy to get right.
