Repository navigation
Multiple BOM symbols inside generated css in v8.5.24 #2133
Description
Hi, I've got following issue after update postcss to latest version.
It's not reproduced on v8.5.23 and lower.
I have sass files in react app, all of them are encoded as UTF-8 without bom (correct encoding is guaranteed by stylelint stylistics lint rule)
old versions:
v8.5.24:
Reacted by Jorrit Schippers
Activity
ai commentedon Aug 11, 2026
Sorry, you need to help us and debug a reason for that since you have an environment to reproduce.
PostCSS does not have code to insert BOM. In that version we fixed cleaning the BOM.
I think here we have a wider ecosystem bug which was hidden by that PostCSS bug of trimming BOM.
Could you at least ask your LLM agent to do a debug.
I will help you with PR when you will find a reason.
elena-konoreva-softwarecountry commentedon Aug 12, 2026
Here is an explanation from AI:
Sass / loader produces BOM on an individual CSS module
↓
PostCSS ≤ 8.5.23 accidentally removes it
↓
everything looks clean
PostCSS 8.5.24
↓
Stringifier intentionally restores BOM
↓
each webpack CSS module retains its BOM
↓
css-loader / MiniCssExtractPlugin concatenate modules
↓
BOM #1 = beginning of file ✅
BOM #2 = middle of file ❌
BOM #3 = middle of file ❌
the exact change is in the following commit:
9a114f6
lib/stringifier.js
ai commentedon Aug 12, 2026
True issue is here. If you concat multiple files you need to remove BOM.
PostCSS previous bug just hided this issue of css-loader. Can you open an issue there?
elena-konoreva-softwarecountry commentedon Aug 12, 2026
I actually cinda fixed this by setting the following option in sass-loader
hchiam commentedon Aug 13, 2026
if i've researched correctly, unfortunately it seems editing the charset option is not recommended, according to the official repo's own notes: "The charset option is true by default for dart-sass. We strongly discourage setting this to false because webpack doesn't support files other than utf-8."
romainmenke commentedon Aug 15, 2026
FYI this isn't an issue for bundlers that use PostCSS itself, like
postcss-import.These produce a single root and won't include multiple BOM's.
I agree with @ai that this is an upstream issue.
PostCSS can't know how its output is used and should remain agnostic of that.
ai commentedon Aug 15, 2026
@romainmenke
css-loaderand other bundlers may use PostCSS for final CSS bundle processing and we can fix upstream issues in that moment #2136romainmenke commentedon Aug 16, 2026
The workaround in #2136 might be fine in practice.
It removes all BOM's found both at the start of a document and between tokens or at the start of tokens.
This removal isn't correct as
U+FEFFis only a BOM if found at the start and has another (deprecated) meaning if found elsewhere, as a zero width no-break space.So if anyone was actually using a zero width no-break space in CSS, this change might be breaking for them. Note that strings should be fine as strings start with a quote mark.
For example:
https://codepen.io/romainmenke/pen/qERzBjP
This is extremely unlikely but still perfectly valid CSS and would be broken by the change in #2136
So fixing it downstream would allow PostCSS to stay true to the specification.
But in practice it is very unlikely that anyone will be affected by this change?
justin-oh commentedon Aug 24, 2026
I found a BOM was inserted after the external
@importlines are moved to the top of the compiled CSS file while the CSS is being interpreted as a non-UTF-8 charset. I thought it was related to sass-loader and made an issue there: webpack/sass-loader#1335.This BOM is interpreted as
by the browser which affects the first CSS selector.fix: postcss를 8.5.23으로 고정하여 향후 BOM 삽입 버그 유입 방지
fix: postcss를 8.5.23으로 고정하여 빌드 CSS의 BOM 삽입 버그 회피