CSS backdrop-filter property disappear in Next.js 15.3.0/15.3.1 dev mode with Turbopack

[RoversX]

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/sweet-lumiere-s7v6jh

To Reproduce

npm run dev

and use chromium core

The backdrop-filter issue specifically occurs in Next.js 15.3.0 and later versions when using Turbopack (next dev --turbo). The problem arises when the CSS properties are ordered with the -webkit-backdrop-filter prefix first, followed by the standard backdrop-filter, like this: -webkit-backdrop-filter: blur(Xpx); backdrop-filter: blur(Xpx);. In this specific ordering under Turbopack, the standard backdrop-filter: blur(Xpx); declaration effectively disappears or is ignored during processing, preventing the blur effect from rendering in non-WebKit browsers. Reversing this order or running without Turbopack resolves the issue.

The current solution is to roll back to nextjs 15.2.5

Current vs. Expected behavior

Current behavior:

When running a Next.js 15.3.0+ project in development mode with Turbopack (next dev --turbo), and CSS is written with the -webkit-backdrop-filter property declared before the standard backdrop-filter property, the standard backdrop-filter rule is seemingly ignored or removed during processing. This results in the blur effect not being applied in browsers that rely on the standard property (like Firefox and modern Chrome/Edge), even though the -webkit- prefixed version might still be present in the processed CSS. The visual effect is that the element has its semi-transparent background, but the content behind it is not blurred.

Expected behavior:

Regardless of whether Turbopack is used or the order in which -webkit-backdrop-filter and backdrop-filter are declared in the source CSS, the Next.js development server should process the CSS correctly, ensuring that both the prefixed and standard properties are output if needed for the target browsers. The visual expectation is that the backdrop-filter: blur() effect should render correctly in all supporting browsers, blurring the content behind the element, consistent with the behavior in production builds or when next dev without Turbopack is used, or with previous Next.js versions (like 15.2.5.2.ehavior in production builds or when next dev without Turbopack is used, or with previous Next.js versions (like 15.2.x) even when using Turbopack.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.4.0: Fri Apr 11 18:33:47 PDT 2025; root:xnu-11417.101.15~117/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 23.11.0
  npm: 10.9.2
  Yarn: N/A
  pnpm: 10.8.1
Relevant Packages:
  next: 15.3.1 // Latest available version is detected (15.3.1).
  eslint-config-next: 15.1.0
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.8.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

create-next-app, Turbopack, CSS

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

[RoversX]

Seems similar to this parcel-bundler/lightningcss#850

[mjulstein]

I am experiencing inconsistencies with CSS modules and what would come out of webpack.

One of the recent bugs I have come over, and I think this has to be experienced on a local computer, is that if I edit CSS inside a CSS module after the initial content has been SSR'ed the rendered output does not change until I hard-reload the page. (Making it very cumbersome to see live updates of CSS changes).
Other times the CSS module may not be used at all during SSR, maybe there is a limit to how much CSS can be processed?
The latter I worked around somehow by making the CSS module part of a layout file.
I believe it worked fine before 15.3.0. (15.3.1 did not fix anything for me)

[timneutkens]

Had a look into this and it's indeed a LightningCSS issue.
Here's what I found so far:

• Reproducing issue on 1.29.1 (latest)
• Reproducing issue on 1.21.0 (issue introduced in this version)
• Not reproducing on 1.20.0 (version where it was fine)

[RoversX]

Had a look into this and it's indeed a LightningCSS issue. Here's what I found so far:

• Reproducing issue on 1.29.1 (latest)
• Reproducing issue on 1.21.0 (issue introduced in this version)
• Not reproducing on 1.20.0 (version where it was fine)

Yeah, I guess we either have to wait for a fix or go back to the old version first until it is fixed.

[dahaca]

@timneutkens, @RoversX, experiencing the same thing in dev mode, sharing some research for everyone interested.

Seems like it's a property ordering issue 🤔 Even on 1.29.1 or latest, if you swap the filter properties, it would affect the result, leaving only the top property in the resulting CSS; in1.20.0 both properties remained. Interestingly enough, if I specify a Safari version < 18 in the playground, the output changes to behave like used to in 1.20.0, which makes sense because post-18 versions do not require the prefix.

For context, I am using pandacss which uses postcss without the autoprefixer by default. Autoprefixer and lightningcss should both output the prefixed property first, yet I see this in my globals.css:

.bkdp_blur\(24px\)_saturate\(1\.1\) {
    backdrop-filter: blur(24px) saturate(1.1);
    -webkit-backdrop-filter: blur(24px) saturate(1.1);
}

It feels like the fact that Chrome ignores the prefixed property is recent behavior and lightningcss is not acknowledging that it's not supported, so it thinks the prefixed is enough and ditches the other? 🤔 Ideally it should realize the prefix one is not supported and output an unprefixed one in this case, requiring a certain order is not reliable at all. Still, not sure where the inverted order comes from 😵‍💫

[RoversX]

@timneutkens, @RoversX, experiencing the same thing in dev mode, sharing some research for everyone interested.

Seems like it's a property ordering issue 🤔 Even on 1.29.1 or latest, if you swap the filter properties, it would affect the result, leaving only the top property in the resulting CSS; in1.20.0 both properties remained. Interestingly enough, if I specify a Safari version < 18 in the playground, the output changes to behave like used to in 1.20.0, which makes sense because post-18 versions do not require the prefix.

For context, I am using pandacss which uses postcss without the autoprefixer by default. Autoprefixer and lightningcss should both output the prefixed property first, yet I see this in my globals.css:

.bkdp_blur\(24px\)_saturate\(1\.1\) {
    backdrop-filter: blur(24px) saturate(1.1);
    -webkit-backdrop-filter: blur(24px) saturate(1.1);
}

It feels like the fact that Chrome ignores the prefixed property is recent behavior and lightningcss is not acknowledging that it's not supported, so it thinks the prefixed is enough and ditches the other? 🤔 Ideally it should realize the prefix one is not supported and output an unprefixed one in this case, requiring a certain order is not reliable at all. Still, not sure where the inverted order comes from 😵‍💫

Ye the problem still exists and I think the easiest way is to roll back to 1.20.0 otherwise I can only stay at next@15.2.5😥

[dahaca]

@RoversX here's is an extremely rough fix but gets the job done:

/**
 * PostCSS plugin to fix backdrop-filter property ordering for lightningcss compatibility
 * Ensures -webkit-backdrop-filter comes before backdrop-filter
 * TODO: remove this once the issue is fixed!!!
 * https://github.com/vercel/next.js/issues/78302
 */
module.exports = () => {
  return {
    postcssPlugin: "backdrop-filter-order-fix",

    /**
     * @param {import("postcss").Rule} rule
     */
    Rule(rule) {
      // Find backdrop-filter declarations
      /** @type {import("postcss").Declaration[]} */
      const backdropDecls = [];

      rule.walkDecls((/** @type {import("postcss").Declaration} */ decl) => {
        if (
          decl.prop === "backdrop-filter" ||
          decl.prop === "-webkit-backdrop-filter"
        ) {
          backdropDecls.push(decl);
        }
      });

      // Only proceed if we have both prefixed and unprefixed backdrop-filter
      if (backdropDecls.length > 1) {
        // Check if reordering is actually needed
        let isReorderingNeeded = false;
        for (let i = 0; i < backdropDecls.length - 1; i++) {
          const current = backdropDecls[i];
          const next = backdropDecls[i + 1];

          // If standard backdrop-filter comes before webkit, we need to reorder
          if (
            !current.prop.startsWith("-webkit-") &&
            next.prop.startsWith("-webkit-")
          ) {
            isReorderingNeeded = true;
            break;
          }
        }

        if (isReorderingNeeded) {
          // Sort backdrop declarations: webkit first, then standard
          const sortedBackdropDecls = [...backdropDecls].sort((a, b) => {
            if (a.prop.startsWith("-webkit-") && !b.prop.startsWith("-webkit-"))
              return -1;
            if (!a.prop.startsWith("-webkit-") && b.prop.startsWith("-webkit-"))
              return 1;

            return 0;
          });

          // Replace each backdrop declaration with its sorted version
          for (let i = 0; i < backdropDecls.length; i++) {
            const originalDecl = backdropDecls[i];
            const sortedDecl = sortedBackdropDecls[i];

            if (originalDecl && sortedDecl) {
              originalDecl.replaceWith(sortedDecl.clone());
            }
          }
        }
      }
    },
  };
};

module.exports.postcss = true;