What is a byte-order mark?

A byte-order mark is the Unicode character U+FEFF placed at the very start of a text stream. Its encoded bytes reveal both the encoding and, for multi-byte encodings, whether the data is big-endian or little-endian.

Should I add a BOM to UTF-8 files?

Usually no. UTF-8 has no byte-order to mark, and a leading EF BB BF can break shell scripts, JSON parsers, PHP output and CSV imports. Most tools expect UTF-8 without a BOM, so omit it unless a specific Windows program requires one.

How do UTF-16 LE and BE differ?

UTF-16 little-endian starts with the bytes FF FE and stores the low byte of each unit first; big-endian starts with FE FF and stores the high byte first. The BOM lets a reader detect the order so the rest of the file is decoded correctly.

Why might a file show a wrong character at the start?

A stray BOM that the application did not strip shows up as the visible sequence ï»¿ (for a UTF-8 BOM mis-read as Latin-1) or a blank character. Detecting and removing the BOM, or telling the parser to expect one, fixes it.

Can UTF-8 and UTF-16 BOMs be confused?

Not if you check enough bytes. A UTF-8 BOM is three bytes EF BB BF, while UTF-16 BOMs are two bytes (FF FE or FE FF) and the UTF-32 LE BOM is FF FE 00 00. Always test the longer sequences first so UTF-32 LE is not mistaken for UTF-16 LE.

BOM Byte-Order Mark Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Identify a file by its first bytes

A byte-order mark (BOM) is the Unicode code point U+FEFF written at the start of a file. Because that single code point encodes to different byte patterns in different encodings, the leading bytes act as a signature: they tell a reader whether the text is UTF-8, UTF-16 or UTF-32, and for the multi-byte forms, which endianness. This reference lists every BOM with its exact hex bytes and lets you paste a file’s opening bytes to detect which one it is.

How it works

The detector reads your hex bytes and tests them against the known signatures, longest first so it cannot mistake a four-byte UTF-32 LE mark (FF FE 00 00) for a two-byte UTF-16 LE mark (FF FE). If the bytes match a signature, the encoding and endianness are reported; if they do not, the file has no BOM — which for UTF-8 is the normal, recommended state. Endianness matters because UTF-16 and UTF-32 store each code unit across multiple bytes, and the BOM fixes whether the most or least significant byte comes first.

Tips and notes

Prefer UTF-8 without a BOM for source code, JSON, CSV and anything consumed by Unix tools — a stray EF BB BF breaks shebang lines, JSON parsers and string comparisons. When you must interoperate with Windows tools that expect a BOM, add it deliberately and document it. For UTF-16 and UTF-32, always emit a BOM or agree the endianness out of band, since there is no other reliable way to recover byte order. When debugging “weird first character” bugs, check for an unstripped BOM before anything else.