Safelist in V4

[SalarHoushvand]

It seems that V4 is not recognizing the colors implemented in the backend (if you are not using the full class name like text-{{ $color }}) . In version 3, I used to safelist them as shown below. How should I handle this in V4?

tailwind.config.js in v3:
, { pattern: /(bg|text)-(slate|gray|zinc|neutral|stone|red|orange|amber|yellow|lime|green|emerald|teal|cyan|sky|blue|indigo|violet|purple|fuchsia|pink|rose)-(50|100|200|300|400|500|600|700|800|900|950)$/, variants: ['dark'] },

[wongjn]

You could consider using the style attribute like:

<div style="color: var(--color-{{ $color }})">

Or

<div style="color: var(--color-{{ $color }}-500)">

Etc

[maheshBawa]

we could do this in v3 as well. but we're using like text-${color}-500, so we can use shades of the color, therefor how can we use shades with this

. this is not a solution.

[kerryj89]

I believe regex patterns and/or variants don't work in v4. In v4 I have to list all 12 statically, e.g. text-left, sm:text-left, md:text-left, lg:text-left, text-center, sm:text-center, and so on.

The following pattern works in v3 but not in v4:

{
  pattern: /text-(left|center|right)/,
  variants: ['sm', 'md', 'lg']
}

[robsontenorio]

Is there any news on how safelist will work in v4?

(not using tailwind.config.js)

[SalarHoushvand]

Nope, so far the only method seems to be working is to have a file with all those classes in it so Tailwind can generate them.

[markau]

This is completely broken.

Of these, only one colour displays on the page when using them dynamically.

  safelist: [
    "bg-blue-300",
    "bg-green-300",
    "bg-yellow-300",
    "bg-orange-300",
    "bg-purple-300",
    "bg-green-300",
    "bg-red-400",
    "bg-orange-400",
]

[cesswhite]

It's true, the safelist isn't working correctly, and having all the classes in a .txt file doesn't seem viable, as I need to include all the bg-gradient-{direction}, via-{}, from-{} classes, which add up to more than 100 classes

[ic-768]

Am also facing the same issue. Have been relying on classes like ${borderWidth} border-${color}-${colorIntensity}, and the removal of safelist is a blocker for me.

[vjanssens]

I don't have a lot of generated colors so ended up creating a tailwind-safelist.blade.php in my Laravel project and adding each color to it as;

<div class="text-green-600"></div>
<div class="text-yellow-600"></div>
<div class="text-red-600"></div>

This get's picked up by the Tailwind compiler and works.

[mbrowne]

FYI for this approach of just ensuring that all the class names are in the code somewhere, they don't have to be used on HTML elements...you could just put them all in a code comment and it should pick them up.

[BeardedGinger]

I can't seem to get this approach to work unless I actively import the safelist file somewhere into the main project. Using v3, it does compile as long as it exists in the paths defined within the config file.

[mbrowne]

Hmm, I was actually updating my Tailwind 3 project in anticipation of upgrading to Tailwind 4, so it's possible I made a bad assumption and it doesn't work anymore in Tailwind 4. But I definitely was able to get Tailwind 3 to pick up additional styles not used in the HTML, without using the safelist option in the config. (In fact I put the classnames in a markdown file, not even an HTML or JS file, and it still picked them up in Tailwind 3.) I did have to update the content option to include my tailwind-safelist.md file.

[robsontenorio]

An solution is to enable support of safelist inside app.css , so we move away from JS config and have same behavior as before.

Because is just very boring to hardcode those classes in somewhere.

[faileon]

The whole v4 update is a fascinating rollercoaster of emotions. Half of the things from v3 are missing and I am baffled how could this even be released in this state. Back to v3 boys and girls.

[pyarun]

i wasted the day in figuring out issues with 4. Now will go back to 3

[grafxflow]

Is it possible to implement something using this as part of the solution? At the moment it seems to only forces the color variables and nothing else.

https://tailwindcss.com/docs/theme

Generating all CSS variables

By default only used CSS variables will be generated in the final CSS output. If you want to always generate all CSS variables, you can use the static theme option:

@theme static {
  --color-primary: var(--color-red-500);
  --color-secondary: var(--color-blue-500);
}

[silenius]

The removal of safelist is also a big issue for me, we have an in-house WYSIWYG editor based on TipTap and now I have to list all possible classes that the editor could set

[edi]

Same here, no safelist support is a bummer ...

[damiandominella]

[wongjn]

That won't really work since it is a dynamic class name. You're better off using a style attribute like:

<div style="background-color: var(--color-${someColor}-400)">

However this might not work either if the --color-<color>-400 variables aren't used anywhere else, since Tailwind will only emit used CSS variables it sees (again, without dynamic string building).

[damiandominella]

Sorry, you're right, my mistake. I forgot to include the step where I needed to safelist the classes. I'm explicitly listing them in a safelist.txt file.

[dizzyjaguar]

Any update on how to best safelist in v4?

[wongjn]

There will be brace-expansion-type syntax with a new @source inline() function, slated for v4.1. See #17147 for details.

[dizzyjaguar]

Very nice, thanks

[FalkoJoseph]

Oh really cool! Keeping an eye on that.

[jessengatai]

This is a complete slop solution.. but just paste your config with your safe list into any decent LLM .. ask it to generate all classnames in a single string separated by spaces.

copy paste the classes onto a hidden div somewhere in your app.

C’est complètement la merde - but it works. whatever.

[wongjn]

As of v4.1, you can use @source inline() to safelist class names.

[FalkoJoseph]

neat, taking a look!

[jessengatai]

That’s great news. I can throw out my slop generated class list.

…

On Sun 6 Apr 2025 at 14:28, Falko Joseph ***@***.***> wrote: neat, taking a look! — Reply to this email directly, view it on GitHub <#15291 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDHLJONTG4WVLFVDL2WBCL2YEMYBAVCNFSM6AAAAABS6ZFEW2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENZUGA3TCMY> . You are receiving this because you commented.Message ID: ***@***.*** com>