[Tailwind v4] Fully Dynamic Class Names from Server-Side Data Not Applied at Runtime

[krishnamk-2604]

What version of Tailwind CSS are you using?

Tailwind CSS v4+

What build tool (or framework if it abstracts the build tool) are you using?

Next.js (App Router) with server-side rendering

What browser are you using?

All major browsers (e.g., Chrome, Firefox)

What operating system are you using?

Windows

We are dynamically injecting utility class names from the server side. For example, the server returns:

{
  "className": "my-4 sm:my-5 md:my-8 lg:my-10"
}

This is applied in the component like so:

<div className={cn(
  "space-y-8 md:space-y-12 lg:space-y-14",
  webPages?.className
)}>
  ...
</div>

Observed Behavior
The combined class string renders correctly in the DOM:

class="space-y-8 md:space-y-12 lg:space-y-14 my-4 sm:my-5 md:my-8 lg:my-10"

However, styles from the dynamically injected classes (my-4, sm:my-5, etc.) are not applied. The base and statically coded classes work correctly. The values are unpredictable, user-configured, and cannot be feasibly safelisted. and is not practical due to unpredictable nature of the data (e.g., hundreds of possible permutations).

[wongjn]

This is unfortunately a limitation of Tailwind because of the way it works. It compiles the CSS at build time. By the time your app is running at runtime, Tailwind is no longer part of the running code.

[krishnamk-2604]

Thank you for the clarification. I understand that Tailwind compiles styles at build time. Just wondering—has the team considered supporting dynamic class names as a feature? I imagine it could unlock more flexibility for use cases where class names depend on runtime conditions (e.g., from user input, CMS content, or config-driven rendering). Is there a technical or philosophical reason why this approach hasn’t been explored or prioritized?

[rozsazoltan]

TLDR: I just listed the ideas that could be considered as alternatives. Personally, I would go with something like solution 04. It's dynamic enough and doesn't require generating unnecessary unused classes.

Solution 01 - Native CSS (I think this is a right way to go.)

Simplest: Use native CSS, but apply TailwindCSS variables within your native CSS classes (e.g., for margin: margin: calc(var(--spacing) * <number>); etc.).

Solution - 02 - Safelist (not recommended)

Alternatively, decide exactly which classes are allowed to be added in the CMS content generator. Once that's done, include them in a safelist before generating the build. (The downside of this is that you'll end up with a compiled CSS file that is heavily bloated with mostly unused classes, which increases server traffic - often unnecessarily.)

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

Solution 03 - CDN (not recommended)

It's a bit of a hacky and not recommended solution, but the CDN version applies the classes correctly at runtime. However, it's definitely not a good idea to use this for production content, as it runs on every visit and every load.

Solution 04 - Generating custom compiled CSS for each CMS content (I think this is a right way to go.)

I'd probably consider something like this. It's dynamic enough. In this case, I think it's worth adding a prefix to the classes written in the CMS content, so they can be distinguished from the default styles of the site.

• How to add tw- prefix to Tailwind CSS classes in a React Vite project with Tailwind CSS v4?

A method that, after the content is assembled, generates the necessary classes for that content using TailwindCSS (e.g., with the help of PostCSS). This way, you can save the full set of required classes for each piece of content.

• Convert TailwindCSS to native CSS? (solution for TailwindCSS v4)
• Convert TailwindCSS to native CSS? (solution for TailwindCSS v3)

The two linked solutions only demonstrate the approach - you'll need to run PostCSS (and through it, TailwindCSS) with JavaScript during CMS content saving in your production code, using the methods described in the answers.

Also, these two answers primarily read the HTML content from files - you'd replace that part so that the CMS content saved in the database is used instead, eliminating the need to traverse folders or files. The TailwindCSS configuration itself can also fit within PostCSS (as I implemented in the answers).

I would run something like this when saving the given CMS content, applied specifically to that content. Then, depending on the size, I'd store the result either in a file or in the database. Finally, I'd make sure that the corresponding CSS is loaded when the CMS content is loaded - either inline or from a file.

[muhammedcantok]

Are there any new alternatives regarding this issue?

[wongjn]

Not new alternatives but not mentioned:

• Use the style attribute for simple styles.
• Use custom css properties:

  <div class="text-[color:var(--my-text-color)]" style={{ '--my-text-color': myDynamicVariableValue }}></div>

• Build up a lookup table of classNames based on some information, from the docs:

  function Button({ color, children }) {
    const colorVariants = {
      blue: "bg-blue-600 hover:bg-blue-500 text-white",
      red: "bg-red-500 hover:bg-red-400 text-white",
      yellow: "bg-yellow-300 hover:bg-yellow-400 text-black",
    };
    return <button className={`${colorVariants[color]} ...`}>{children}</button>;
  }

[yudin-s]

Tailwind cannot generate classes that only appear after your app is already running. Seeing the class string in the DOM is not enough; the matching CSS has to exist in the built stylesheet.

For user/server-defined spacing like this, I would avoid storing raw Tailwind class strings as open-ended runtime data. Better options:

1. Store structured design tokens, then map them to known classes in code:

const spacing = {
  compact: 'my-4 sm:my-5 md:my-8 lg:my-10',
  relaxed: 'my-8 sm:my-10 md:my-12 lg:my-16',
} as const

<div className={cn(base, spacing[webPages.spacing])} />

2. Store CSS variables instead of classes:

<div
  className="my-[var(--section-y)] md:my-[var(--section-y-md)]"
  style={{
    '--section-y': '1rem',
    '--section-y-md': '2rem',
  } as React.CSSProperties}
/>

3. If the CMS must accept Tailwind-like classes, compile CSS for that content at save/publish time and load that generated CSS with the page.

The key is to move from “unbounded runtime class names” to either a finite allow-list, structured tokens, CSS variables, or a separate compile step. Runtime Tailwind class generation is intentionally not part of the production build model.