Tailwind v3 → v4 Colour Migrator
Paste the colours out of tailwind.config.js and get the CSS-first @theme block v4 expects, with every value converted to OKLCH. Nothing is silently dropped — values that cannot be resolved are listed instead of disappearing.
Tailwind v3 colours
Tailwind v4 @theme
The converted block appears here. Nested keys join with a dash and DEFAULT drops to the bare name, which is how v4 reads them back as utility classes.
Frequently asked
What exactly changes between v3 and v4?
In v3 colours lived in a JavaScript config under theme.colors. In v4 they live in CSS, inside an @theme block, as custom properties named --color-*. The nesting flattens: brand.500 becomes --color-brand-500, and a DEFAULT key drops to the bare name, so brand.DEFAULT becomes --color-brand. Those names are what generate bg-brand-500 and bg-brand again.
Why convert the values to OKLCH?
Because that is what v4's own palette uses, and mixing notations makes a theme hard to reason about. OKLCH is perceptually uniform, so equal lightness steps look equal to the eye. The conversion is lossless for anything inside the sRGB gamut — your hex values come back the same colour.
What happens to the <alpha-value> placeholder?
It is removed. In v3 you needed rgb(0 0 0 / <alpha-value>) so Tailwind could inject opacity when you wrote bg-black/50. In v4 the colour functions carry opacity themselves and the placeholder is no longer part of the syntax.
It says a value could not be resolved. Why?
Because it is not a literal colour. Values pulled from tailwindcss/colors, spread from another object, or built from a JavaScript variable only exist when the config runs, and this tool never runs your code — it reads the text. Paste the resolved value instead, or copy that part across by hand.
Does my config get uploaded anywhere?
No. The parsing and conversion happen in your browser and nothing is sent to a server. The tool also never evaluates what you paste — it normalises the text and reads it as data, so a config cannot execute here.