npx tailwindcss init -p Does Not Exist in Tailwind v4

If npx tailwindcss init -p is failing, it is almost certainly because you installed Tailwind CSS v4, which removed that command entirely — configuration moved from a JavaScript file into your CSS, so there is no config file to generate.

This is the most common Tailwind upgrade surprise, and the error message does not explain it. Every tutorial written before v4 opens with that command, so people follow one, hit a failure, and reasonably conclude the installation is broken. It is not. Here is what changed, what to run instead, and how to stay on v3 if you would rather not migrate today.

Table of contents

• What the command used to do
• Setting up Tailwind v4
• Configuration moved into CSS
• Staying on v3, and what else changed
• How this fits the rest of the stack
• FAQ

What the command used to do

In Tailwind v3 and earlier, npx tailwindcss init generated a tailwind.config.js at the project root, and the -p flag additionally generated a postcss.config.js wired with Tailwind and Autoprefixer.

// tailwind.config.js, v3
module.exports = {
  content: ['./src/**/*.{html,js,jsx,ts,tsx}'],
  theme: {
    extend: {
      colors: { brand: '#7f62f4' },
    },
  },
  plugins: [],
};

That file was where everything lived: which files to scan for class names, your theme extensions, and any plugins. The content array in particular was mandatory — get it wrong and Tailwind generated no styles for the classes you were using, which was the other classic v3 confusion.

v4 removed both the command and the requirement. There is no config file by default, and content detection is automatic — Tailwind scans your project and works out which files to look at without being told.

So the command did not break. It was deleted, because the thing it produced is no longer part of the design.

Setting up Tailwind v4

The v4 setup is genuinely shorter. Two steps for the CLI path:

npm install tailwindcss @tailwindcss/cli

Then a single line in your CSS entry point, replacing the three @tailwind directives v3 required:

@import "tailwindcss";

And build:

npx @tailwindcss/cli -i ./src/input.css -o ./src/output.css --watch

Note the package name change: the CLI is now @tailwindcss/cli, a separate package from tailwindcss. Running npx tailwindcss without installing that package is another route to a confusing failure.

For a build tool, use the dedicated plugin rather than PostCSS. With Vite, install @tailwindcss/vite and add it to the plugins array — it is faster than the PostCSS path and is the recommended route. If you do need PostCSS, the plugin is @tailwindcss/postcss, not tailwindcss as it was in v3, which is another silent breakage during an upgrade.

Configuration moved into CSS

Theme customisation in v4 happens in your stylesheet using the @theme directive, with values expressed as CSS custom properties.

@import "tailwindcss";

@theme {
  --color-brand: #7f62f4;
  --color-brand-dark: #6b4fd8;
  --font-display: "Inter", sans-serif;
  --spacing-huge: 8rem;
}

Those definitions generate utilities in the usual way — bg-brand, text-brand-dark, font-display, p-huge — and they are also real CSS custom properties, available at runtime to your own CSS and to JavaScript. That is a genuine improvement over the v3 arrangement, where theme values existed only at build time.

The naming convention is structural rather than arbitrary: the prefix determines which utility family the value joins. --color-* creates colour utilities, --font-* font-family utilities, --spacing-* spacing utilities, --breakpoint-* responsive breakpoints.

Other directives that replace v3 config concepts: @plugin for plugins, @source to point at content Tailwind’s automatic detection would miss (a template inside a dependency, say), and @utility for custom utilities.

If you have an existing tailwind.config.js you are not ready to convert, @config "./tailwind.config.js"; loads it, which makes an incremental migration possible rather than all-or-nothing.

Staying on v3, and what else changed

If you are following a v3 tutorial or maintaining an existing project, pinning the major version is entirely reasonable:

npm install -D tailwindcss@3
npx tailwindcss init -p

That works exactly as documented in every pre-2025 guide. v3 is stable and there is no urgency to migrate a working project.

If you are upgrading, the official codemod handles most of it — npx @tailwindcss/upgrade converts config, directives and renamed utilities. Run it on a clean branch and read the diff. The changes to expect:

• Browser requirements. v4 targets Safari 16.4+, Chrome 111+ and Firefox 128+, because it relies on modern CSS features including cascade layers and @property. If you must support older browsers, stay on v3 — this is the one genuinely blocking difference.
• Renamed utilities. shadow-sm is now shadow-xs, shadow is shadow-sm, and the same shift applies to rounded and blur. The codemod handles these.
• Removed deprecated utilities. text-opacity-*, bg-opacity-* and friends are gone in favour of the slash syntax — bg-black/50.
• Default border colour. It changed from gray-200 to currentColor, which can subtly alter appearance in places you had relied on the default.
• No more @tailwind directives. The single @import "tailwindcss"; replaces all three.

The performance improvement is substantial — full builds several times faster and incremental rebuilds dramatically so — which is the main practical reason to migrate once browser support allows.

How this fits the rest of the stack

A CSS build step is exactly the kind of thing that works locally and fails in CI on a different Node version or a missing dev dependency, which is why a build log you can read matters more than the config file. The RunxBuild hosting calculator covers what the deployed result costs across the service, storage and bandwidth. RunxBuild builds static sites straight from a repository with the build log and the runtime log in the same place, and rollback to the previous working deploy as a single action.

Useful related references:

• Python init.py: What It Actually Does, and When Empty Is Correct
• What Does init Do in Python? It Sets Up Each Object, and self Is How
• Change Linux Hostname: hostnamectl, /etc/hosts, and the cloud-init Override
• Services on RunxBuild

FAQ

Why does npx tailwindcss init -p not work?

Because you have installed Tailwind CSS v4, which removed the init command entirely. Configuration moved from tailwind.config.js into your CSS using the @theme directive, so there is no config file to generate. Nothing is broken — the command no longer exists.

How do I set up Tailwind CSS v4?

Install tailwindcss and @tailwindcss/cli, add a single @import “tailwindcss”; line to your CSS entry point, and run the CLI with input and output paths. For a build tool, use the dedicated plugin such as @tailwindcss/vite rather than the PostCSS path.

Where is tailwind.config.js in Tailwind v4?

There is not one by default. Theme values are declared in CSS with the @theme directive as custom properties, and content detection is automatic. If you have an existing config you are not ready to convert, @config ”./tailwind.config.js”; loads it so migration can be incremental.

How do I install Tailwind v3 instead?

npm install -D tailwindcss@3, then npx tailwindcss init -p works exactly as described in pre-2025 tutorials. Pinning to v3 is reasonable for an existing project or if you need to support browsers older than Safari 16.4, Chrome 111 or Firefox 128.

What changed between Tailwind v3 and v4?

Configuration moved into CSS, the @tailwind directives were replaced by one @import, the PostCSS plugin is now @tailwindcss/postcss, several shadow, rounded and blur utility names shifted by one step, opacity utilities were removed in favour of slash syntax, and the default border colour became currentColor. Browser requirements also rose.