Weird CSS corruption when using Tailwind utilities in stylesheets

[UP-MDK]

Hello,

since i am not sure if that is a bug, or just not allowed to do, i wanted to ask first.

To reproduce the issue:

1. Set up a next.js project with tailwind
2. write components with tailwind
3. use a custom additional stylesheet with references to tailwind utility classes in it

Unfortunately, this may or may not lead to immediate CSS corruption. But at some point, i get CSS generated, that is not wrote by myself. In other words, the compiler must be mixing up classes and generates CSS rules that don't exist.

Therefore, i wanted to ask if it may generally be not allowed to use utility classes in selectors of custom CSS?

Code example:

/* custom and native tailwind utility classes used in an overrides.css */
header:is(.bg-white, .bg-primary-20, .bg-secondary-0) h1 {
    /* note, that writing color: #hex; won't solve the issue here, in case anyone is wondering whether circular referencing might be the problem */
    @apply text-primary-100;
}

Corrupted output:

In this case, the rule written is generated + other rules that do not exist.
Note, that in some cases the actual rule you write won't even be generated.

I would be happy to recieve any kind of help, since this issue is affecting production and i don't know what to do.

Best regards,
Marius

[salimuddin07]

1. Using Tailwind classes in custom CSS selectors

Tailwind’s @apply is meant for applying utility classes inside CSS rules, not for referencing them in selectors directly. For example:

.my-header {
  @apply text-primary-100 bg-white;
}

But this:

header:is(.bg-white, .bg-primary-20, .bg-secondary-0) h1 {
  @apply text-primary-100;
}

can confuse the JIT compiler because:

.bg-primary-20 and other Tailwind utilities are generated classes, not normal CSS selectors.

Tailwind’s compiler does not guarantee that you can use its classes inside complex selectors (like :is() or chained selectors). It may produce “corrupted” output or drop rules because it tries to tree-shake unused utilities.

In short: Tailwind encourages using @apply for utilities, but not using utility classes as part of your selectors.

2. Why you see “corrupted CSS”

Tailwind’s JIT engine scans your source files (JSX, HTML, CSS) for class names.

When you put utility classes in selectors like header:is(.bg-white, ...) h1, the compiler may misinterpret them or generate invalid output because they appear in a selector context rather than in a class attribute or @apply.

Some rules might disappear, and some unrelated rules might appear — this is the “corruption” you’re seeing.

3. Recommended approaches

Option A – Use @apply inside regular selectors:

header.my-header h1 {
  @apply text-primary-100;
}

Then in your JSX:

<header className="bg-white">
  <h1 className="my-header">Hello</h1>
</header>

Option B – Add custom variants if needed

If you really need conditional styles for multiple backgrounds, you can use Tailwind’s variants or write custom classes:

.bg-primary-20 h1 {
  @apply text-primary-100;
}

.bg-secondary-0 h1 {
  @apply text-primary-100;
}

Option C – Avoid referencing Tailwind classes in :is()

Tailwind is not designed to support selectors like this. You should define a new custom class and apply Tailwind utilities inside it:

.header-title {
  @apply text-primary-100;
}

Then in JSX:

<header className="bg-white bg-primary-20 bg-secondary-0">
  <h1 className="header-title">Hello</h1>
</header>

✅ Key takeaway:
Tailwind utilities should be used with @apply or as class names, not as raw selectors in CSS. Using them in selectors like :is() is likely to break the JIT engine and produce unexpected output.

[wongjn]

@apply can cause unexpected side effects like this. I would convert any @apply statements that use or reference an class selectors you use. So it wouldn't be enough to convert that single rule to color: <color>. You'd need to remove any @apply bg-white, @apply bg-primary-20 and @apply bg-secondary-0. This is because the @apply from those are trying to transpose themselves onto the rule in your OP.

[UP-MDK]

@salimuddin07

Thanks for you answer! I was expecting something like that. What's funny is, that i wanted to mark your answer as answer but Github marked it as spam instead. LOL?

What i don't quite understand yet is in Option B, why would this be valid?

.bg-primary-20 h1 {
  @apply text-primary-100;
}

.bg-secondary-0 h1 {
  @apply text-primary-100;
}

Isn't it doing the same thing?

[salimuddin07]

Hi

Both rules apply the same utility class (text-primary-100) to the h1 element, but they’re scoped differently:

In the first case:

.bg-primary-20 h1 { ... }

The text color will only apply to h1 elements inside an element with bg-primary-20.

In the second case:

.bg-secondary-0 h1 { ... }

The same text color applies to h1 elements inside an element with bg-secondary-0.

So yes, the applied utility is the same, but the context (parent background class) is different. That’s why both are valid — you might want to keep text color consistent across different background sections.

If you don’t need different parent selectors, you could simplify by just applying the class directly to the h1 itself instead of scoping it.

[UP-MDK]

Thanks again, but that is not what i meant.
I meant, how is that generally different from what i have been doing all along?

Isn't it still using the tailwind utility as selector, which you said is not advised?

To be clear, this is solving my issue for now. But i don't understand why
Thank you anyway!

[salimuddin07]

you’re right that it looks similar to “using a Tailwind utility class as a selector,” which normally isn’t recommended. The difference here is subtle:

In your original approach, you were trying to directly extend or redefine Tailwind’s own utility classes (like writing .text-primary-100 { … }). That’s what Tailwind warns against, because it can break internal generation and lead to conflicts.

In this option (.bg-primary-20 h1 { @apply text-primary-100; }), you’re not redefining Tailwind utilities. Instead, you’re creating a new custom CSS rule that uses a Tailwind utility inside. Tailwind is totally fine with this, because apply is the recommended way to compose utilities in your own selectors.

[UP-MDK]

Sorry, maybe i was not clear, but .bg-primary-20 is in fact also a tailwind utility class just as .text-primary-100. I configured these as custom utility classes via tailwind.config.js.
So this should still redefine the tailwind utility?