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.

[rozsazoltan]

Since this is a previously accepted top answer, I'll add a note here that starting from v4.1, it is possible to define inline sources. With this, instead of providing file paths where TailwindCSS class names are used, we can list specific class names using a special syntax. Specifically, in response to the question asked here:

• Safelist in V4 #15291 (reply in thread)

[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>

[m-shum]

Would be great to have some additional documentation on how to whitelist multiple classes, not just states. For example, this code is from a production codebase currently using v3:

  safelist: [
    {
      pattern: /(mt|mb|my|mx|ml|mr|pl|pr|pt|pb|py|px|bg|text|color)-./,
    },
    {
      pattern: /(aspect)-./,
    },
  ],

The v4 docs don't appear to have a list of all the built-in number classes for padding, margin, height, etc. The documentation for --spacing() is pretty sparse too, so outside of hunting down the values for margins and padding in either v3 docs or external sources, how would you even whitelist all that with @source inline?

This might seem like an edge case, but being able to safelist these kinds of classes is a pretty fundamental need when working with page builders like Storyblok.

[wongjn]

So in v4, there is an unlimited number of built-in number classes that use --spacing(), i.e., you can have p-1 or p-1234567, so it's up to you to decide how many spacing steps you want to safelist.

[m-shum]

Ah I guess that makes sense since it's a calc() with a --spacing variable. Never occurred to me that it was limitless. Good to know, thank you!! Do you know if there's a way to safelist multiple variants of a class like padding with the same values? Instead of having to @source for p, then px, then py, then pt, so on and so on, it would be great to just encapsulate them all in one line since they should use the same number classes.

[wongjn]

There is a way to safelist multiples of similar classes with the same values. Use brace expansion syntax like:

@source inline("p{x,y,t,b,l,r}-{1..10}");

And then if you wanted to incorporate margin into this:

@source inline("{m,p}{x,y,t,b,l,r}-{1..10}");

https://play.tailwindcss.com/3wKykd69qY?file=css

[m-shum]

This is exactly what I'm after, thank you @wongjn!
This is very handy and definitely needs to be added to the documentation – I'm sure I won't be the last person looking for this information.

[RobinMalfait]

You can find the docs for this here: https://tailwindcss.com/docs/detecting-classes-in-source-files#safelisting-specific-utilities

[rozsazoltan]

Here, I have created a brief description related to the topic:

• Safelist in Tailwindcss 4. Is it possible? Pattern + Variants?

Examples

I will highlight my examples used here in this discussion as well:

@source inline('{sm:,md:,lg:,xl:,}grid-cols-{1,2,3,4,5,6,7,8,9,10,11,12}');

• Test yourself in TailwindCSS Playground with Generated CSS

@source inline('{sm:,md:,lg:,xl:,}grid-cols-{{1..12..1}}');

• Test yourself in TailwindCSS Playground with Generated CSS

@source inline('{sm:,md:,lg:,xl:,}grid-cols-{1,{10..90..5}}');

• Test yourself in TailwindCSS Playground with Generated CSS

@source inline("p{x,y,t,b,l,r}-{1..10}");

• Test yourself in TailwindCSS Playground with Generated CSS

@source inline("{m,p}{x,y,t,b,l,r}-{1..10}");

• Test yourself in TailwindCSS Playground with Generated CSS

@source inline('underline');
@source inline('{hover:,}bg-red-{50,{100..900..100},950}');

• Test yourself in TailwindCSS Playground with Generated CSS

[rozsazoltan]

export default {
  safelist: [
    {
      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"],
    },
  ],
}

Specifically, my primary answer to the question asked here would be: is it really necessary? This results in a very large number of classes in the compiled CSS, which drastically increases the file size. If you're using this on a website, it means every visitor has to download a lot of unnecessary classes; which may not be the best way to write your code.

On the other hand, if you still insist on doing it, this is how it should be written:

@source inline('{dark:,}{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..900..100},950}');

• Test yourself in TailwindCSS Playground with Generated CSS

Extra

@source inline('{sm:,md:,lg:,xl:,}grid-cols-{1,2,3,4,5,6,7,8,9,10,11,12}');

Note: Since there are variants, a comma indicates that we also want the plain class name version. So, request grid-cols-{1..12} even without a variant. If we don't add a comma after sm, md, lg, or xl, then the plain version won't be included in the compiled CSS, only the sm, md, lg, and xl variants will be.

@source inline("p{x,y,t,b,l,r}-{1..10}");

Note: Here, I didn't add a comma at the end of the x,y,...,l,r list; but if I did, it would also generate the p-1, p-2 classes.

@source inline("{m,p}{x,y,t,b,l,r}-{1..10}");

Note: You can see that I didn't add a comma at the end of the m,p list to avoid declaring meaningless plain x-1, y-2, ... classes.

• Source: How is it possible to specify a safelist in TailwindCSS v4? Is it possible to list patterns and variants instead of full class names?

[abdallah-shaltout]

@source inline("{hover:,}bg-red-{50,{100..900..100},950}");
check this link
https://tailwindcss.com/docs/detecting-classes-in-source-files#safelisting-specific-utilities

[asolopovas]

this doesn't seem to work if you have prefix set. It won't generate media queries only the @layer utilities section. Is there a workaround ?

@import "tailwindcss" prefix(tw);
@source inline("{md:,lg:,xl:,}tw:grid-cols-{1..12}");

[rozsazoltan]

The correct syntax is that the prefix is always at the beginning of the class. Therefore, you cannot place it in the middle.

https://play.tailwindcss.com/pt0oVpWJZm?file=css

@import "tailwindcss" prefix(tw);

@source inline("tw:{md:,lg:,xl:,}grid-cols-{1..12}");

• https://tailwindcss.com/docs/upgrade-guide#using-a-prefix

<div class="tw:flex tw:bg-red-500 tw:hover:bg-red-600">
  <!-- ... -->
</div>

<div class="tw:grid-cols-1 tw:md:grid-cols-2">
  <!-- ... -->
</div>

[asolopovas]

definitely needs to be added to docs could not find anything about prefix, or safelist. Thanks again.

[RobinMalfait]

You can find more info about it here:

• https://tailwindcss.com/docs/upgrade-guide#using-a-prefix
• https://tailwindcss.com/docs/styling-with-utility-classes#using-the-prefix-option

[rozsazoltan]

Although when you need 12x4, that is 48 classes, it is more practical to consider a custom class that dynamically handles the number of columns maybe by CSS-variables.

https://play.tailwindcss.com/5ZRo2LMHOL?size=482x720&file=css

@utility grid-cols-dinamically {
  --current-grid-col-num: var(--grid-col-num, 1);
  grid-template-columns: repeat(var(--current-grid-col-num, 1), minmax(0, 1fr));

  @variant md {
    --current-grid-col-num: var(--grid-col-num-from-md);
  }

  @variant lg {
    --current-grid-col-num: var(--grid-col-num-from-lg);
  }

  @variant xl {
    --current-grid-col-num: var(--grid-col-num-from-xl);
  }
}

<div class="grid grid-cols-dinamically" style="--grid-col-num: 2; --grid-col-num-from-md: 3; --grid-col-num-from-lg: 6; --grid-col-num-from-xl: 9;">
  <div>1</div>
  <div>2</div>
  <div>3</div>
  <div>4</div>
  <div>5</div>
  <div>6</div>
  <div>7</div>
  <div>8</div>
  <div>9</div>
</div>

It can be used for an infinite number of columns and your generated CSS will be much smaller. It's completely normal to mix this with the original utilities. The original utilities are primarily maintained for immediate use in HTML, but if you don't use them directly in your project, it's worth considering more dynamic solutions.

Generated CSS with Inline SafeList	Generated CSS with dynamically alternative

The difference isn't many bytes, but small savings add up, especially if you're planning the server's data traffic for a larger number of users. Otherwise, it’s 217 lines of generated CSS while the HTML content is still just... wtf.