{"id":330,"date":"2026-06-16T05:00:26","date_gmt":"2026-06-16T05:00:26","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/tailwind-css-v4-config-file-i-deleted\/"},"modified":"2026-06-16T05:00:26","modified_gmt":"2026-06-16T05:00:26","slug":"tailwind-css-v4-config-file-i-deleted","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/tailwind-css-v4-config-file-i-deleted\/","title":{"rendered":"Tailwind CSS v4: The Config File I Finally Deleted"},"content":{"rendered":"

Confession: I used to copy my tailwind.config.js<\/code> from project to project like a lucky charm. I didn’t fully understand every line in it. I knew which block set my colors and which block set my breakpoints, and the rest was cargo cult. If you’d asked me what the content<\/code> array globbing actually did under the hood, I’d have changed the subject.<\/p>\n

Tailwind CSS v4 quietly took that file away from me, and after the initial “wait, where did my config go” panic, I like it a lot more than I expected. The short version: configuration moved out of a JavaScript file and into your CSS, the engine got dramatically faster, and a few things I used to fake (like container queries) are now first-class. Here’s the before-and-after on the parts that changed how I actually work.<\/p>\n

The config file I finally deleted<\/h2>\n

In v3, theme customization lived in JavaScript. You’d extend the theme, restart the dev server, and hope you spelled colors<\/code> right.<\/p>\n

\/\/ tailwind.config.js (v3)\nmodule.exports = {\n  content: [".\/src\/**\/*.{html,js,jsx,ts,tsx}"],\n  theme: {\n    extend: {\n      colors: {\n        brand: { DEFAULT: "#2563eb", dark: "#1e3a8a" },\n      },\n      fontFamily: {\n        sans: ["Inter", "sans-serif"],\n      },\n    },\n  },\n};\n<\/code><\/pre>\n
In v4, that moves into your CSS with the @theme<\/code> directive. One import, no JavaScript config file for the common cases, and the values become real CSS variables you can read anywhere.<\/p>\n
\/* app.css (v4) *\/\n@import "tailwindcss";\n\n@theme {\n  --color-brand: #2563eb;\n  --color-brand-dark: #1e3a8a;\n  --font-sans: "Inter", sans-serif;\n}\n<\/code><\/pre>\n
Now bg-brand<\/code> works, and so does var(--color-brand)<\/code> in any hand-written CSS, because the theme tokens are just variables. The first time I needed my brand color inside a tiny bit of custom CSS, I didn’t have to import anything from a JS object. It was already there. The v4 upgrade guide<\/a> covers the migration path, including the automated tool that handles most of it for you.<\/p>\n
Automatic content detection, or the glob I stopped maintaining<\/h2>\n
The content<\/code> array was the source of my most embarrassing bugs. Add a new folder, forget to update the glob, and your classes silently don’t generate in production. I lost an afternoon to that exact mistake more than once.<\/p>\n
v4 detects your template files automatically using heuristics based on your .gitignore<\/code>, so the glob is gone for the common project layout. You can still point it at specific sources with @source<\/code> when you need to, but I haven’t needed to on a normal app. The detecting classes docs<\/a> explain when the automatic behavior won’t cover you, which is mostly when your markup lives somewhere unusual or in a dependency.<\/p>\n
That’s one whole category of “why isn’t this style showing up” debugging that just left my life.<\/p>\n
Container queries without the plugin tax<\/h2>\n
This is the one I’m happiest about. In v3, responsive design keyed off the viewport. If you wanted a card that adapted to its container instead of the screen, you reached for the official container-queries plugin and installed yet another dependency.<\/p>\n
<!-- v3: needed @tailwindcss\/container-queries plugin -->\n<div class="@container">\n  <div class="@md:flex @md:gap-4">...<\/div>\n<\/div>\n<\/code><\/pre>\n
v4 bakes container queries into core. Same @container<\/code> and @md:<\/code> syntax, no plugin to install.<\/p>\n
<!-- v4: built in -->\n<div class="@container">\n  <div class="grid @md:grid-cols-2 @lg:grid-cols-3 gap-4">...<\/div>\n<\/div>\n<\/code><\/pre>\n
Why does this matter? Because real components don’t know how wide the screen is. They know how wide their slot is. A card in a sidebar and the same card in a main column want different layouts, and viewport breakpoints can’t tell them apart. I wrote up the messy way I used to fake this in how I stopped faking responsiveness with container queries<\/a>, and v4 is the version where I finally stopped.<\/p>\n
The thing that makes container queries click is when you build a genuinely reusable component, like a product card you drop into a three-column grid, a two-column grid, and a narrow drawer, all in the same app. With viewport breakpoints you end up passing a size<\/code> prop or writing three variants. With container queries the card just reads its own width and adapts, and you stop maintaining the variants entirely. That’s the moment it goes from a neat trick to something I reach for by default.<\/p>\n
The speed I didn’t ask for but won’t give back<\/h2>\n
v4 rewrote the engine, partly in Rust, and full builds got several times faster while incremental rebuilds dropped into the low single-digit milliseconds. The official v4.0 announcement<\/a> has the benchmarks, and your mileage depends on project size, but the practical effect for me was that the dev feedback loop stopped having a perceptible Tailwind step at all. Save, see the change. That’s it.<\/p>\n
I’ll be honest that speed wasn’t on my list of complaints about v3. It was fine. But once the rebuild is instant you notice how often you were unconsciously waiting, and you don’t want to go back.<\/p>\n
New things in the utility layer worth knowing<\/h2>\n
A few smaller changes shifted how I write utilities day to day. The spacing scale is now dynamic, generated from a single --spacing<\/code> base, so values like p-13<\/code> or mt-17<\/code> just work instead of failing because nobody happened to define them in the default scale. I used to add one-off spacing values to my config constantly. That whole habit is gone.<\/p>\n
Colors moved to the OKLCH color space, which sounds academic until you make a color slightly lighter and it stays the same hue instead of drifting muddy the way sRGB sometimes did. The default palette is more vivid on modern displays for the same reason. You don’t have to do anything to get this; it’s just how v4 ships.<\/p>\n
The other one I reach for is the @utility<\/code> directive for custom utilities, which replaced the old @layer utilities<\/code> plus addUtilities<\/code> plugin dance. If I want a content-auto<\/code> utility, I write it once in CSS and it participates in variants and hover states like a built-in.<\/p>\n
\/* v4 custom utility *\/\n@utility content-auto {\n  content-visibility: auto;\n}\n<\/code><\/pre>\n
None of these are headline features. Together they’re the reason I stopped opening a JavaScript config file reflexively every time I wanted something slightly custom. The custom value is usually a one-liner in CSS now, or it already exists because the scale is dynamic.<\/p>\n
What this costs you<\/h2>\n
It’s not free. v4 dropped support for older browsers; it targets Safari 16.4, Chrome 111, and Firefox 128 and up, because it leans on modern CSS features like cascade layers and @property<\/code>. If you have to support older browsers, stay on v3, and that’s a real constraint, not a footnote. The upgrade tool is good but not magic on heavily customized configs, so budget an afternoon for a large project rather than five minutes.<\/p>\n
A concrete thing to do this week: spin up a throwaway project with npm install tailwindcss@latest<\/code>, move your color palette into an @theme<\/code> block, and delete the JS config. Fifteen minutes will tell you whether the CSS-first approach clicks for you the way it did for me. If you want more of how I decide which framework changes are worth adopting, I keep notes on that across my projects<\/a>. I came into v4 grumpy about losing my config file and left it having deleted three other things I didn’t miss either.<\/p>\n","protected":false},"excerpt":{"rendered":"
Tailwind CSS v4 moves config into CSS, auto-detects content, and bakes in container queries. Before-and-after code on what changed and what it costs you.<\/p>\n","protected":false},"author":2,"featured_media":329,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"Tailwind CSS v4 moves config into CSS, auto-detects content, and bakes in container queries. Before-and-after code on what changed and what it costs you.","rank_math_focus_keyword":"tailwind css v4","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[137,35],"tags":[37,38,369,370,172],"class_list":["post-330","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-css","category-web-development","tag-css","tag-frontend","tag-tailwind-css-2","tag-tailwind-v4-2","tag-web-development-2"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/330","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=330"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/330\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/329"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=330"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=330"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=330"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}