What goes in a website style guide
Before you extract anything, know what you are hunting for. A good style guide answers one question over and over: "which value do I use here?" These are the sections that earn their place:
- Color palette. Every color the site uses, grouped by job: brand, text, backgrounds, borders, states. How often a color appears matters. A color used 400 times is a core color. A color used twice is probably a mistake, and knowing that saves you from copying it.
- Typography. The fonts that actually load (sites often declare fonts they never use), the weights available for each, and the type scale: which sizes exist and where each one shows up (headings, body, captions).
- Buttons. Padding, radius, background, and the hover, focus, and active states. The states are the part everyone misses, because you cannot see them in a screenshot. They are also why a rebuilt button so often feels dead compared to the original.
- Spacing scale. The handful of margin, padding, and gap values the site keeps repeating. Most well-built sites settle on 6 to 10 values.
- Assets. Logos, icons, and illustrations, in their original formats.
- Voice. The mature version also covers writing: how formal, how long the sentences run, whether the site says "we" or "you".
How to build a style guide manually with DevTools
Everything above lives in the page, and DevTools can show you all of it. Open the site, press Cmd+Option+I (or F12), and work through the systems one at a time.
1. Colors
Start where the site names its own colors. In the Sources panel, search the CSS for :root. Many sites define their palette as CSS variables with names like --color-brand, and those names tell you what each color is for, which is the half of the job a color picker cannot do. Then click through a few real elements (a heading, a paragraph, a card border) in the Elements panel and read their colors from the Styles pane to confirm which variables actually get used where. It is a sampling exercise, not a census, and that is fine: you want the eight colors that matter, not all forty that technically appear.
2. Typography
First find out which fonts really load. Open the Network panel, filter by Font, and reload the page. Each file listed is a font the site genuinely uses, including the individual weight files. Then select an h1, some body text, and a caption in Elements and read font-size, line-height, and font-weight from the Computed tab. Write down the scale you find, something like 48 / 32 / 24 / 16 / 13.
3. Buttons and states
Select a button in Elements. In the Styles pane, click the little :hov toggle and force :hover, then :focus, then :active, one at a time. Watch what changes (usually background, border, shadow, or a slight move) and copy those properties. Repeat for every button variant. This is the tedious part, and it is the step people skip. Do not skip it. The states are the whole reason the original button feels alive.
4. Spacing
Inspect a dozen representative elements (cards, sections, list items) and note their computed padding, margin, and gap values. Then deduplicate your list. If the numbers cluster around multiples of 4 or 8, you have found the site's grid. Write the scale down as, say, 4 / 8 / 12 / 16 / 24 / 32 / 64.
5. Assets and assembly
Logos and icons are in the Network panel under the Img filter: right-click a request, open it in a new tab, save it. Then pull everything into one document. A practical format is a single CSS file of variables plus a short note explaining what each one is for. Budget one to two hours for a typical marketing site, more for an app with lots of component variants.
The faster way: a style guide generator extension
Sitegeist is a free Chrome extension that does all of the above in one click. It analyzes the page locally in your browser (activeTab permission, nothing leaves the browser), and its tabs map straight onto the sections you just read about:
- Colors tab → color palette. The full palette with usage counts and the selectors each color came from, so you get both the numbers and the intent without digging through Sources.
- Typography tab → type section. The type scale plus the fonts that actually loaded, with each weight listed and variable fonts flagged.
- Buttons tab → component section. Real buttons recreated with their hover, focus, and active states. This is the :hov work from step 3, already done.
- Spacing tab → spacing scale. The repeated spacing values, deduplicated for you.
- Assets tab → asset library. Previews with single-image download (downloading everything at once is a Pro feature).
- Voice tab → tone of voice. A writing profile covering reading grade, sentence length, point of view, and how often the site uses contractions.
It also shows the tech stack, SEO checks, discovered sitemaps, and a content outline, and an inspect overlay gives you a tidy style summary for any single element you point at. If you are comparing tools in this space, see how Sitegeist stacks up against CSS Scan, CSS Peeper, and Hoverify.
Exporting to CSS variables, Tailwind, or JSON tokens
A style guide you cannot paste into a project is just a nicer screenshot. The useful end state is tokens in whatever format your project speaks.
CSS custom properties (free). Sitegeist's free tier exports the extracted palette, type scale, and spacing as CSS variables. The output is ready to drop into your stylesheet and looks like this:
:root {
--color-brand: #4f46e5;
--color-ink: #111827;
--font-size-lg: 24px;
--space-4: 16px;
}
Tailwind config (Pro). If your project uses Tailwind, the Pro export maps the extracted values into a config, so bg-brand and text-lg resolve to the source site's real values instead of Tailwind's defaults.
JSON design tokens (Pro). For teams running a token pipeline, the JSON export is a machine-readable file you can feed into whatever transforms your build already runs.
Pro is $19.99 one time and also adds batch asset download, full-page screenshots, full authored CSS and HTML copy in inspect mode, and a copyable voice style prompt. Treat the free tier as the trial: run a teardown, spot-check a few values against DevTools, and upgrade only if the exports actually save you time.
