Tailwind Class Sorter

Tailwind class strings have a recommended order — layout, then box model, then typography, then visual — but no human consistently follows it across a codebase. The result is class strings where some have flex p-4 text-sm bg-blue-500 and others have bg-blue-500 text-sm p-4 flex, which is fine until you're scanning fifty components looking for a specific utility.

Paste a class string and the sorter returns it in the order Tailwind's official Prettier plugin uses. Useful for bringing legacy code into line, normalizing snippets pasted from documentation or AI suggestions, and producing consistent diffs in code review. The sort order matches the prettier-plugin-tailwindcss algorithm so output is identical to what the plugin would produce on save.

A one-off paste here, but for ongoing work, configuring the Prettier plugin in your editor is the better long-term answer.

The sort order Tailwind's official Prettier plugin uses is the recommended order from the Tailwind docs, encoded into the plugin so every project gets identical output regardless of who edited the file last. Roughly: layout properties first (display, position, top/right/bottom/left, z-index, float), then flex/grid (which control how children behave), then box model (width, height, margin, padding), then typography (font, text), then visual decoration (background, border, shadow), then transforms and transitions. Variants like md:, hover:, dark: sort with their underlying utility, not as a separate variant block. The reason for this order is reading: when scanning a class string, the first few classes tell you what kind of element this is, then how it sizes itself, then how it looks.

A worked example: an unsorted class string flex p-4 text-sm bg-blue-500 hover:bg-blue-600 rounded-lg w-full md:w-auto. Sorted: flex w-full rounded-lg bg-blue-500 p-4 text-sm hover:bg-blue-600 md:w-auto. Layout (flex), sizing (w-full), then visual (rounded, bg), then box (p), then typography (text), then variants in the same order. Now every component in your codebase that uses these utilities reads the same way, and a quick visual scan tells you flex, full-width, then visual properties — a level of code review that's impossible when each component arranges classes randomly.

The limitation: sorting is purely syntactic and doesn't understand your component's intent. If you have a class string with conflicting utilities (e.g., p-4 px-2 — both apply, the more specific one wins by source order in Tailwind v3 or by layer in v4), the sorter preserves whichever ordering Tailwind expects but doesn't flag the conflict. The sort changing nothing semantically is the design — sorting should never change rendered output. Detecting conflicts is a separate problem that linters (eslint-plugin-tailwindcss) handle.

For production use, the right answer is configuring prettier-plugin-tailwindcss in your editor and CI so files are sorted on save and on PR. The web tool here is for one-off cleanups, AI-generated snippets that need normalization, and code-review situations where you want to see what the sorted version would look like before merging.