This is a normal thing to want. You are taking over a codebase whose design decisions were never written down, or matching a component to a system somebody else owns, or checking whether the site you are about to redesign has a scale at all.

The build is not a black box. It is a set of decisions, flattened — and most of them survive the flattening.

Version 4 hands it to you

Tailwind 4 moved the theme into CSS. A @theme block compiles to custom properties on the root element, and custom properties are readable at runtime, in order, with their computed values.

the theme, read off a live page

const root = getComputedStyle(document.documentElement);

[...document.styleSheets]
  .flatMap((s) => [...s.cssRules])
  .filter((r) => r.selectorText === ':root')
  .flatMap((r) => [...r.style])
  .filter((name) => name.startsWith('--color-'))
  .map((name) => [name, root.getPropertyValue(name).trim()]);

So on a version 4 site the theme is not inferred at all. It is read — every token the build kept, under the name the author gave it, which is the part that matters:

What comes back off a version 4 build: the token, its name, and the value it resolves to. The name is the half a screenshot of the site could never give you. — runs on the page itself.

--color-brand-600 tells you something that #0e7490 does not. The names are the design system. The values are only its output.

The names are also the fastest way to date a codebase. A palette named for its role — surface, rule, ink, danger — is a system somebody maintained. A palette named blue-1 through blue-9 is a palette somebody pasted.

Version 3 has to be inferred

Before the theme lived in CSS it lived in a config file that never shipped. What ships is the generated utilities — and the scale is recoverable from them, because every generated class is a name-value pair. .text-slate-700 carries the value of slate-700 in its own declaration.

• Collect every rule whose selector is a Tailwind-shaped class.
• Group by the utility prefix — text-, bg-, p-, rounded-, shadow-.
• Read the declared value out of each rule.
• Take the breakpoints from the @media queries the rules are nested inside.

It is arithmetic on a stylesheet rather than analysis. The gap is that a version 3 build only emits what was used: the config may have carried forty greys, and the stylesheet carries the nine somebody wrote a class for.

Reading the scale rather than the colours

Colour is the part everybody recovers first and the part that matters least — a palette can be lifted from a screenshot. The spacing scale cannot, and it is the thing that makes a new component look like it belongs.

every spacing value the page actually uses, ranked

const seen = new Map();

for (const el of document.querySelectorAll('*')) {
  const s = getComputedStyle(el);
  for (const side of ['paddingTop', 'marginBottom', 'gap']) {
    const v = s[side];
    if (v && v !== '0px' && v !== 'normal') {
      seen.set(v, (seen.get(v) ?? 0) + 1);
    }
  }
}

[...seen].sort((a, b) => b[1] - a[1]).slice(0, 12);

The output tells you two things at once. A tidy result — 8px, 16px, 24px, 32px, each used hundreds of times — is a scale somebody kept to. A long tail of 13px, 19px, 27px used twice each is a scale that exists in the config and not in the codebase, which is a different finding and a more actionable one.

Breakpoints

Read from the @media queries in the stylesheet, deduplicated. Faster than any documentation, and correct by construction.

Radii and shadows

Small, closed sets. Three radii is a system; eleven is a codebase where every component chose for itself.

Type scale

The computed font-size and line-height pairs actually in use. The pairing is the part a config file lists and a page proves.

What is gone for good

Anything tree-shaken

A token defined and never used is indistinguishable from a token that never existed. True in both versions.

Plugin configuration

Custom variants, container queries, typography plugin settings. The output is visible; the switch that produced it is not.

The reasoning

You can recover that the spacing scale steps by 4 pixels. You cannot recover that the team agreed to it in a meeting, or that step 6 is deliberately absent.

The names, in version 3

#0e7490 is in the stylesheet. Whether the team called it accent-deep or cyan-700 is not — unless the class list happens to say so.

What to do with what you get

The recovered theme is a starting file, not an answer. Three things are worth doing with it before it is useful:

1. Sort each scale and look at the gaps. A colour ramp missing its 400 step, or a spacing scale with two values eleven pixels apart, is where the system was patched rather than extended.
2. Count the uses. A token used once is a decision somebody made in a hurry; a token used four hundred times is the system. The count is the difference between a palette and a scale.
3. Name what you recovered, if the build could not. On a version 3 site you are handed values without names, and writing the names down is the act that turns a list of hex codes back into a design system.

One honest caution: a recovered theme is evidence about the shipped page and nothing more. It cannot tell you which values were deliberate, and it will happily present an inconsistency as a scale. Treat it as a survey, not as documentation.

The used subset is the useful subset

This reads like a limitation and mostly is not. If you are matching a component to a site, the values in the shipped stylesheet are exactly the values in use — the recovered theme is the live one, with the aspirational parts already removed.

Where it does matter is auditing, and there it cuts the other way. A recovered scale with eleven greys in it is not proof that eleven greys were designed. It is proof that eleven greys were shipped — which is the more useful of the two findings, and the one no config file would have told you.

Start with the honest version: there is no signature. A model can produce markup indistinguishable from a person's, and a person can produce markup indistinguishable from a model's. Anybody selling certainty here is selling a coin flip with a progress bar.

What there is, is texture. Generated pages tend to carry several habits at once, and the habits are measurable even though none of them is wrong on its own.

The habits worth counting

Utility-class verbosity

Forty classes on one element, the same spacing scale repeated at three different values, colour utilities that never resolve to a token.

Structural padding

A paragraph wrapped in eleven nested div elements, each with one child, none of them doing anything.

Copy patterns

Headings built from the same six adjectives, three-item lists everywhere, a call to action that says nothing.

Accessibility theatre

aria-label on an element that already has an accessible name, roles restating what the tag already means.

Runtime artifacts

State written on every render, effects with dependency lists that cannot be right, the same fetch issued twice.

Any one of these is normal. A design system produces long class strings; a component library nests; a careful engineer in a hurry writes an aria-label that was not needed. The signal is the co-occurrence, not the habit.

one element, five habits at once

<div class="flex flex-col gap-4 space-y-4 p-4 px-4 py-4
            text-base leading-normal font-normal">
  <div>
    <div>
      <p aria-label="paragraph" role="paragraph">
        Unlock the power of seamless, cutting-edge solutions.
      </p>
    </div>
  </div>
</div>

<!-- gap-4 and space-y-4 do the same job and fight.
     p-4 is overridden twice by its own components.
     Two wrapper divs hold one child each.
     role="paragraph" is not a role.
     The sentence names no product and no outcome. -->

Why the calibration matters more than the rules

Any of those, on its own, is normal. A design system produces long class strings. A component library nests. A careful developer writes an aria-label because a screen reader needed it.

So the number that matters is not how many rules can fire, it is how the weighted total behaves on work that is unambiguously hand-written. The target was set the other way round from the obvious one: a tool that flags careful work is worse than no tool, because it teaches the reader to ignore it — and once ignored, it never catches the real thing either.

That is a harder direction to tune. Catching generated output is easy; leaving good work alone while still catching it is the whole engineering problem.

A score has to show its working

A number with no method behind it is an opinion wearing a lab coat. Every finding says what it measured — the count, the element, the threshold it crossed — and offers a concrete change.

This has a practical consequence: the score is arguable. Somebody who disagrees can point at the rule that fired and say why it is wrong in their case, and sometimes they will be right. That is the design working, not failing. A verdict nobody can interrogate is one nobody should act on.

It also sets the standard for us. If a rule cannot be defended when somebody pushes back on it, the rule comes out.

What a score cannot tell you

• Whether a model wrote it. There is no signature, and any tool claiming otherwise is selling certainty it cannot have.
• Whether the page is bad. A high score on a landing page that converts is a finding about maintenance cost, not about quality.
• Whether it was reviewed. Generated code that a person read, understood and kept is not a defect. The score measures texture, and texture survives review.
• Anything about the code you cannot see. This reads the rendered page. The repository behind it may be immaculate or may not exist.

The right reading of a high score is "this page has more of the habits than most" — and then the finding list, which is the part that is actually actionable.

What it is for

Not for judging other people's work — although that is what it will get used for, and pretending otherwise would be silly.

The use that pays: run it on a page you just shipped fast. The findings are a refactor list ordered by how much they cost, which is the list you were going to write by hand anyway, on the day you had no time to write it.