Remove a UTF-8 BOM From a Text File
Read the file using automatic detection, write it as UTF-8 and leave byte-order mark turned off. The leading EF BB BF marker is consumed during decoding and is not written to the new file; the text itself and, by default, every line ending remain unchanged.
A plain-text file up to 25 MB. Binary formats such as Word documents are not text encodings and are refused.
Results are provided as-is, with no warranty of accuracy. The method and its sources are published below so you can check the working.
A UTF-8 BOM is three bytes—EF BB BF—at the start of the file.
Removing it changes the encoding marker, not the first visible character.
The complete conversion happens in the browser and produces a separate file.
How it works
How it is done
- Inspect the first three bytes for EF BB BF (UTF-8), FF FE (UTF-16LE) or FE FF (UTF-16BE). In automatic mode the marker chooses the decoder; without one, require UTF-8 rather than guessing a legacy code page.
- When the source encoding is selected manually, require any existing marker to agree. Remove the agreed marker, then decode in fatal mode so an illegal byte sequence stops the conversion instead of becoming a silent replacement character.
- Preserve every CR, LF and CRLF sequence by default. Only when selected, normalise all three forms to LF or to CRLF as a separate operation from character encoding.
- Count Unicode code points, treating a valid UTF-16 surrogate pair as one supplementary character. Encode the resulting string as UTF-8 bytes or as two-byte UTF-16 code units in the selected byte order.
- Add the selected target marker—EF BB BF, FF FE or FE FF—only when requested, then offer a separate .txt file. The source file is never changed.
What it assumes
- Auto is intentionally bounded to the three Unicode byte-order marks. An unmarked file defaults to strict UTF-8; Windows-1252, ISO-8859 variants and other legacy code pages cannot be distinguished reliably from bytes alone.
- A byte-order mark at the start is metadata and is consumed before the first text character. A U+FEFF later in the file is content and remains content.
- UTF-8 has no byte-order question; its BOM is only a signature. UTF-16LE and UTF-16BE serialize the same 16-bit code units in opposite byte order.
- Invalid UTF sequences are refused instead of repaired. The input cap is 25 MB, and the code-point and UTF-16 loops yield every 250,000 code units for progress and cancellation.
Common questions
Why can a BOM appear as strange characters?
Software that decodes the bytes with the wrong legacy encoding may display EF BB BF as visible text. A Unicode-aware decoder consumes the marker before exposing the first character.
Will removing the BOM change CRLF line endings?
Not with Preserve exactly selected. BOM handling and line-ending conversion are separate controls.
Sources
The full method, worked example and every assumption behind this figure are on Text Encoding Converter.