Why Your Colour Tokens Disappear, Even When the Colours Look Right
The page comes back the right colour. The variables you defined are not what drives it. Here is the mechanism, and the prompt wording that makes your tokens win.
7
min read

Table of Contents
Your palette does not lose an argument with the model. It gets copied into a theme that was already there, and the theme keeps the steering wheel.
Correction, 30 September 2026. This article was first published under the title Why AI Ignores the Colours in Your Prompt. That was wrong. Measuring the colours the browser actually paints, rather than searching for hex strings in the stylesheet, shows that the palette usually does arrive. What goes missing is the token structure behind it, which is what this corrected version is about.
We gave 154 websites an exact palette in the prompt, written as CSS custom properties. Then we checked the result two ways.
By string match, only 33 per cent of the specified hex values appear in the compiled stylesheet. By colour measurement in a real browser, the page background is visually indistinguishable from a prompt colour on 82 per cent of sites and close on 88 per cent.
Both numbers describe the same build. The palette lands. The definitions do not.
What is really in your stylesheet
These builds start from a template that already has a complete design system wired into it, and the fingerprints are in the compiled CSS of almost every site we measured.
82 per cent of sites carry the standard component theme variables, identifiable by names like
--popover-foregroundthat no prompt of ours ever mentioned.52 per cent define colours in
oklch(), the modern Tailwind default notation, not something we asked for.The median compiled stylesheet is 75 kB, most of it theme and utility classes rather than anything specific to the design.
So when you paste a :root block with your paper, ink and accent colours, you are usually not replacing that system. The build reads your intent, produces the right colour, and writes it into its own theme in its own notation. The page looks correct. Your variable names are not what any component references.
Why that costs you something real
On launch day this is invisible, which is exactly why it is worth knowing about.
The cost arrives later, in three predictable ways. Changing your accent means finding every place the value was copied to rather than editing one definition. Anything you add afterwards, a new section or a pasted component, inherits the template default instead of your palette. And the parts you never named, the focus ring, the form field border, the disabled state, the chart colours, stay generic because they were never yours to begin with.
That last one is the reason a site can look like your design and still feel subtly off the moment anyone interacts with it.
How to write it so the tokens win
Three changes, in order of how much they matter.
Override the theme tokens by name, not just your own. Do not only define
--paperand--ink. Say the existing theme variables must be redefined to your values, and name them: background, foreground, primary, secondary, muted, border, ring.Say it must replace, not extend. One sentence: the default theme must be overwritten rather than supplemented, and no component may keep a default colour.
Ask for a check you can verify. Require that no colour appears anywhere in the code except the tokens you defined, which gives you something you can confirm by searching the file rather than by squinting at the page.
A wording that works:
Check it in ten seconds
Open the published site, view the stylesheet and search for --popover. If it is there and your token names are not, the original theme is still in control, however right the page looks.
This is a different test from searching for your hex value, and it is the more useful one. Your colour being absent as a string tells you very little, because it may simply have been converted. Your token names being absent tells you that you have a picture of a design system rather than a design system.

