prettier-plugin-tailwindcss: sorting Tailwind classes with Prettier

What prettier-plugin-tailwindcss solves, and who it is for

Tailwind classes are order-independent. `p-4 m-2` and `m-2 p-4` produce the same CSS, so every developer invents a private convention and every diff review turns into an argument about spacing. prettier-plugin-tailwindcss removes that argument by sorting classes according to Tailwind's recommended class order, the same sequence documented in the Tailwind blog post on automatic class sorting with Prettier. The sorting is deterministic, so two developers who run Prettier on the same file get byte-identical output.

The audience is narrow and specific: projects that already run Prettier v3 or later and already use Tailwind CSS v3.0 or later. If you do not run Prettier, this plugin has nothing to hook into. If you run Prettier but not Tailwind, it does nothing. The repository is TypeScript, MIT licensed, and the last push was on 2026-09-01. The most recent release listed is v0.8.1 from 2026-07-15, preceded by v0.8.0 and v0.7.4, both dated 2026-04-27.

How the sorting actually works

The plugin registers itself with Prettier and walks the parsed syntax tree looking for class strings. By default it handles the `class` attribute plus framework equivalents the README names explicitly: `className`, `:class`, `[ngClass]`, and Tailwind `@apply` directives. It also sorts strings passed to named functions and tagged template literals when you configure those names.

To decide the order, the plugin needs Tailwind's own context, because custom utilities and theme extensions change where a class belongs in the sequence. For Tailwind v4 the README says you must point at your CSS entry point with the `tailwindStylesheet` option. For Tailwind v3 it reads `tailwind.config.js`, looking in the same directory as your Prettier configuration unless you override it with `tailwindConfig`. Paths in both options resolve relative to the Prettier configuration file, not the file being formatted. That last detail is the source of most setup confusion in monorepos.

The plugin also exposes the sorting logic without Prettier through a separate entrypoint, `prettier-plugin-tailwindcss/sorter`. You import `createSorter`, pass a `base` directory and either a `stylesheetPath` or a `configPath`, and get back an object with `sortClassAttributes` for space-separated strings and `sortClassLists` for arrays of class names. That is the escape hatch for build tools and editor integrations that do not want to run Prettier.

Installing prettier-plugin-tailwindcss and sorting your first file

The README gives a single install command, adding the plugin as a dev dependency alongside Prettier itself:

npm install -D prettier prettier-plugin-tailwindcss

Then the plugin has to be registered in your Prettier configuration. The README's minimal example is a `.prettierrc` file:

{
  "plugins": ["prettier-plugin-tailwindcss"]
}

If you use a JavaScript config instead, the README shows importing the plugin's option types for editor IntelliSense:

// prettier.config.js

/** @type {import('prettier').Config & import('prettier-plugin-tailwindcss').PluginOptions} */
export default {
  plugins: ["prettier-plugin-tailwindcss"],
}

At this point running Prettier over a file with a `className` containing `rounded bg-blue-500 px-4 py-2 text-base text-white` should leave that string in the order shown, because the README presents that exact order as sorted output. To prove the plugin is active, write the classes in a scrambled order and format the file; if nothing changes, the plugin is not being loaded.

On Tailwind v4 you must add the stylesheet path, or the plugin cannot see your theme:

{
  "tailwindStylesheet": "./resources/css/app.css"
}

On Tailwind v3 with a config outside the Prettier config directory, point at it explicitly:

{
  "tailwindConfig": "./styles/tailwind.config.js"
}

The README states that if a local configuration file cannot be found, the plugin falls back to the default Tailwind configuration. That fallback is silent, which is why the sorted output can look correct while custom utilities land in the wrong position.

Sorting classes the default pass misses

Two groups of class strings are invisible to the plugin until you name them. The first is non-standard attributes. The README suggests `tailwindAttributes`, an array of attribute names, and it accepts regex patterns enclosed in forward slashes. The README notes that JS regex literals are not supported with Prettier, so the pattern must be a string:

{
  "tailwindAttributes": ["myClassList", "/data-.*/"]
}

With that configuration the README's example sorts classes in `myClassList` and in any attribute starting with `data-`, such as `data-theme` and `data-classes`. The second group is classes inside function calls, which is where conditional class libraries live. The README names clsx and cva as the motivating case and shows `tailwindFunctions` taking a list of function names:

{
  "tailwindFunctions": ["clsx"]
}

The same option covers tagged template literals. The README's example uses `twrnc` in React Native with `tw` as the tag, and it also documents writing your own identity function so the plugin has something to match:

const tw = (strings, ...values) => String.raw({ raw: strings }, ...values)

The cost of these options is configuration drift. Every new helper function or wrapper component that builds class strings is a name someone has to remember to add, and a missed name means that file silently stops being sorted.

Where prettier-plugin-tailwindcss stops being the right tool

The plugin sorts literal class strings it can see in the syntax tree. It cannot reason about classes assembled at runtime from a variable, a database value, or a string concatenation that Prettier parses but the plugin does not recognize. If your codebase builds class names dynamically in a way that never produces a static string, the plugin will pass over it, and no amount of configuration fixes that.

The second limitation is the ESM-only decision made in v0.5.x. The README states plainly that as of v0.5.x the plugin requires Prettier v3 and cannot be loaded via `require()`. Projects still on Prettier v2, or CommonJS configs that load plugins through `require`, are out until they migrate. The README links an upgrade guide in the issue tracker rather than documenting the migration inline.

The third is scope. This is a formatter plugin, not a linter. It will not warn you about a conflicting utility, an unused class, or a class that does not exist in your theme. It rewrites order and nothing else. Teams looking for correctness checks are reaching for the wrong package.

The alternative: doing nothing, or sorting elsewhere

The obvious alternative is to skip class sorting entirely and let each developer order classes however they like. That works on small teams and fails the moment more than one person touches the same component, because there is no shared reference order and diffs fill with reordered class strings that change no rendering.

A more interesting comparison is between this plugin and other Prettier plugins that reorder class strings. The repository's own dev dependencies include `@ianvs/prettier-plugin-sort-imports` and `@trivago/prettier-plugin-sort-imports`, which sort import statements rather than class attributes. They solve a different problem: import ordering is about module resolution and side effects, while class ordering is about Tailwind's specificity-independent sequence. Neither replaces the other, and a project can run both.

The genuine difference in approach shows up with the sorter entrypoint. Instead of running Prettier, you can import `createSorter` and call the sorting functions directly, which suits a custom build step or an editor plugin that already has a parsed class string and does not want a full format pass. The trade-off is that you now own the integration: resolving `base`, `configPath` and `stylesheetPath` correctly is your responsibility, and the plugin's own defaults no longer apply.

Maintenance cost, licence and what to check before adopting

The package is MIT licensed, and the published `files` field contains only `dist`, so installing it does not pull source or tests into your tree. The build step is `tsdown`, the test runner is `vitest`, and the publish script copies licence files, which suggests third-party licence text is bundled into the distributed output. If your organisation audits dependency licences, that bundled text is the thing to inspect rather than the top-level MIT declaration alone.

Upgrade cost is dominated by the Prettier v3 and ESM-only requirement introduced in v0.5.x. Once you are past that boundary, the plugin tracks Tailwind's own major versions, so a Tailwind v4 migration forces you to add `tailwindStylesheet` and stop relying on `tailwind.config.js` discovery. The README does not document a rollback path or a compatibility matrix beyond the version requirements, so pinning the plugin version in your lockfile is the practical safeguard. The repository was last pushed on 2026-09-01 and is not archived.

Editorial conclusion

Adopt it if your team already runs Prettier and wants one deterministic class order in JSX, Vue, Angular, Marko or Liquid templates without a separate lint rule. Skip it if you are on Prettier v2, if you need a CommonJS require, or if your class strings are assembled at runtime where no formatter can see them. Before wiring it into CI, confirm your Prettier version, set tailwindStylesheet for Tailwind v4 or tailwindConfig for v3, and check that the plugin actually finds the stylesheet: if it cannot, the README states it falls back to the default Tailwind configuration and your custom utilities will sort in the wrong place.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. tailwindlabs/prettier-plugin-tailwindcss on GitHub