How to Fix: Autoprefixer Not Enabled by Default in create-next-app

Autoprefixer is expected to be part of the default CSS toolchain in a modern Next.js app, especially when the project is generated with Tailwind CSS. But in some create-next-app setups, vendor prefixes are not applied because Autoprefixer is either missing from dependencies, not wired through PostCSS, or overridden by a custom configuration.

Understanding the Root Cause

This issue appears when a freshly generated app does not run Autoprefixer as part of its PostCSS pipeline. In a standard Next.js + Tailwind setup, CSS processing usually flows like this:

CSS source -> PostCSS -> Tailwind CSS plugin -> Autoprefixer plugin -> browser-ready output.

If autoprefixer is not installed, omitted from postcss.config.js, or replaced by a custom config that only includes tailwindcss, the final CSS is generated without vendor prefixes. That can break compatibility for features that still need prefixes in some browsers, such as certain flexbox or appearance-related rules.

With create-next-app, this can happen for a few practical reasons:

• The generated template installs tailwindcss but does not add autoprefixer explicitly.
• A user customizes postcss.config.js and accidentally removes the plugin.
• The project uses a newer package combination where assumptions about implicit PostCSS behavior no longer hold.
• Dependencies were installed inconsistently due to lockfile or package manager resolution issues.

In short, the bug is not that CSS fails entirely. The real problem is that the PostCSS plugin chain is incomplete, so browser compatibility enhancements never run.

Step-by-Step Solution

The fix is to ensure that autoprefixer is installed and explicitly configured in the project.

1. Install the required packages

If the app was generated without Autoprefixer, add it manually:

npm install -D autoprefixer postcss tailwindcss

Or with Yarn:

yarn add -D autoprefixer postcss tailwindcss

Or with pnpm:

pnpm add -D autoprefixer postcss tailwindcss

2. Verify your PostCSS configuration

Create or update postcss.config.js so it includes both tailwindcss and autoprefixer:

module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
}

If your project uses the array format, this is also valid:

module.exports = {
  plugins: [require('tailwindcss'), require('autoprefixer')],
}

3. Confirm Tailwind is still connected correctly

Your global stylesheet should still include the standard Tailwind directives:

@tailwind base;
@tailwind components;
@tailwind utilities;

4. Restart the Next.js development server

After changing dependencies or PostCSS config, restart the server:

npm run dev

5. Validate that prefixes are being generated

Add a CSS rule that commonly shows prefixed output after processing:

.test-prefix {
  appearance: none;
  user-select: none;
}

Then inspect the compiled CSS in the browser or build output. You should see generated prefixed variants depending on your browserslist targets.

6. Define browser support targets if needed

Autoprefixer relies on Browserslist rules. If your project has no meaningful browser targets, prefixing may appear minimal. Add this to package.json if needed:

{
  "browserslist": [
    "defaults",
    "not dead",
    ">0.2%"
  ]
}

This tells Autoprefixer which browser matrix to optimize for.

7. Recommended final project check

A healthy setup should include:

• autoprefixer in devDependencies
• postcss in devDependencies
• postcss.config.js with autoprefixer configured
• Valid Tailwind CSS directives in your stylesheet
• Optional browserslist configuration for expected compatibility output

Common Edge Cases

Custom postcss.config.mjs or ESM projects

If your project uses ESM, CommonJS syntax may fail silently or be ignored depending on the toolchain. Use an ESM-compatible config:

export default {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
}

Autoprefixer is installed but still not running

This usually means another PostCSS configuration file is taking precedence, or the CSS being tested is not processed by the Next.js build pipeline. Check for duplicate config files such as postcss.config.cjs, postcss.config.js, and postcss.config.mjs.

Prefixes are missing for properties you expect

That is not always a bug. Autoprefixer only adds prefixes when current browser support data says they are needed. If your Browserslist targets are modern, some rules will remain unprefixed.

Monorepo workspace issues

In a monorepo, the app may resolve postcss or autoprefixer from the wrong package boundary. Make sure the Next.js app itself can resolve the dependency and its config locally.

Tailwind v4 or alternative CSS pipeline changes

If the project uses a newer Tailwind architecture or custom CSS tooling, the traditional PostCSS + Autoprefixer setup may differ. In that case, confirm whether prefixing is handled by the new pipeline or still requires explicit configuration.

Lockfile drift after project generation

If create-next-app generated the app during a version transition, deleting node_modules and the lockfile, then reinstalling, can resolve incomplete dependency trees:

rm -rf node_modules package-lock.json
npm install

FAQ

Does Next.js include Autoprefixer automatically?

Not always in a way you can safely assume for every generated template and version combination. The reliable fix is to verify that autoprefixer is installed and listed in postcss.config.js.

Why does Tailwind work even when Autoprefixer does not?

Tailwind CSS and Autoprefixer do different jobs. Tailwind generates utility classes, while Autoprefixer rewrites final CSS for browser compatibility. Tailwind can function normally even if vendor prefixing is missing.

How can I test whether Autoprefixer is actually enabled?

Add rules like appearance or user-select, run the build, and inspect the output CSS. You can also review the configured plugin list in your PostCSS config and confirm your browser targets with Browserslist documentation.

The most dependable resolution for this issue is simple: treat Autoprefixer as an explicit part of your Next.js CSS pipeline, not an assumption hidden inside scaffolding. That guarantees consistent browser compatibility regardless of template changes in create-next-app.