CSS Color Extractor

Nobody decides to use fifty colours. What happens instead is that each individual change is reasonable — a developer matches a mockup by eye, a component arrives from another project with its own greys, a hover state gets darkened by a few percent inline, a third-party widget brings its own brand colour. Because CSS has no mechanism that objects to a new literal value, none of these decisions is ever flagged. The drift only becomes visible when you look at every colour in the file at once, which is the point of extracting them.

The natural next step after an audit is to give the colours you keep a name. Define them once as custom properties on :root, group them by role rather than appearance — a token called --text-muted survives a rebrand in a way that --grey-6 does not — and replace the literals as you touch each rule. This is not a change you have to make all at once. Consolidating the few colours that appear most often already removes most of the ambiguity, and it gives future changes a single place to happen.

Mostly for auditing a palette you did not design. Inheriting a stylesheet and wanting to know what colours it actually uses, checking whether a redesign has been applied consistently, or finding the seven slightly different greys that accumulated because nobody knew a token already existed — those are the cases where a flat list beats reading the file. It is also a fast way to build the starting point for a set of CSS custom properties, since you can see which values repeat often enough to deserve a name.

It looks for hex, rgb, rgba, hsl, and hsla values, which is how the large majority of production CSS specifies colour. Named keywords such as red or rebeccapurple are not collected, and neither are var() references, since the value of a custom property is defined elsewhere and only resolved at runtime. If your stylesheet is built on design tokens, run the file that defines those tokens — that is where the literal values live.

Because palettes drift. Colours arrive from design handoffs, from copied components, from a developer eyedropping a mockup, and from third-party CSS, and none of those routes checks whether a similar value already exists. A stylesheet with a documented palette of eight colours routinely turns out to use fifty. Seeing them listed together is what makes the duplication obvious, and consolidating onto custom properties is what stops it recurring.

Not directly — contrast is a relationship between two colours, so a flat list cannot tell you whether any specific text passes. What it gives you is the inventory: once you know a stylesheet uses a particular grey for body text, you can check that grey against your background colours in a contrast checker. For real accessibility auditing, test the rendered page with a tool like Lighthouse or axe, since those see the combinations that actually occur.

No. Every one of these tools runs entirely in your browser using JavaScript. Your stylesheet is never uploaded, never logged, and never sent to any server — you can confirm this by opening your browser devtools Network tab while you work, or by disconnecting from the internet after the page loads and watching everything continue to function. That makes it safe to paste proprietary or client CSS.