Every designer and frontend developer eventually does the same thing: open DevTools, click through computed styles, and try to reconstruct someone else's palette from screenshots and guesswork. It works. It is also a waste of an afternoon when what you actually need is the tokens - colors, fonts, CSS variables - as they appear on the page.
Extracting design tokens from a live site is not theft of creativity. It is how you study systems, match a brand for a prototype, or scaffold a theme before you redesign it on purpose.
What "design tokens" means in practice
On a real website, tokens show up as:
- Hex / RGB / HSL colors used in CSS and inline styles
- CSS custom properties (
--color-*,--space-*, theme variables) - Font families and sizes that define the type scale
- Occasionally gradients, borders, and surface colors that act as the visual system
A moodboard is vibes. Tokens are what you paste into a stylesheet or a Figma variable set. If you are reverse-engineering a reference, you want tokens.
Manual extraction: what people usually do
- Screenshot the page and eyedrop colors in Figma or a color picker
- Inspect a few elements and copy hex values one by one
- Dig through the Styles panel for
:rootvariables - Miss half the palette because it only appears on hover, dark mode, or a secondary route
Screenshots lie about contrast and compression. Hand-picking five "main" colors ignores the neutrals that actually do most of the layout work. CSS variables are the ground truth when the site uses them - and many modern sites do.
A better mental model
Think in layers:
Surfaces - backgrounds, cards, page chrome.
Text - body, muted, headings.
Accent - links, buttons, focus rings.
Feedback - success, warning, error if they exist.
When you harvest colors, group them that way instead of dumping a flat list of fifty hex codes. You will redesign faster and avoid shipping a rainbow of near-duplicates.
Typography is part of the token set
Color alone is not a system. Note the primary UI font, any display/serif pairing, and the rough scale (body vs H1). Sites that look "premium" often spend more intention on type than on a sixth brand color.
Dark mode and state variants
Many sites ship two palettes. If you only scrape the default theme, you will miss the dark-mode neutrals that carry most of the UI at night. Toggle themes when you can, or note that your extract is "light only" so you do not invent a half-system.
Hover, focus, and disabled states also hide colors. You do not need every micro-state on day one, but button and link colors that only appear on :hover are easy to miss in a casual eyedrop pass.
Contrast and honesty
Pulling tokens is the start. Checking whether the combination meets WCAG contrast is the part people skip. If you are scaffolding a theme for production, run key pairs through a contrast checker before you call it done. Pretty and unreadable is still a failed extract.
Client-side extraction
Prefer tools that analyze in the browser rather than uploading a URL to a random server. You often work against staging sites, logged-in dashboards, or local previews - and you should not need to ship those to someone else's backend to read CSS.
That is the problem I kept hitting, so I built a client-side extractor for palettes, typography cues, and CSS-variable-style output.
Pair the tokens with a contrast check (WebAIM is fine), then decide what to keep. Related on the same hub: LangSwap for snippet ports.