What is a byte-order mark?

The BOM is the Unicode codepoint U+FEFF placed at the start of a file. In UTF-16 it signals endianness, but in UTF-8 there is no byte order, so it acts purely as a signature that the file is UTF-8. It is encoded as the three bytes EF BB BF.

Why would I add a BOM?

Some applications, notably older versions of Microsoft Excel, only recognise a CSV file as UTF-8 if it begins with a BOM. Without it, accented characters and other non-ASCII text are misread. Adding the BOM fixes the import.

Why would I remove a BOM?

Many tools treat the BOM as unexpected data. A leading BOM can break shell scripts, PHP output, JSON parsers, and concatenated files by inserting invisible characters at the start. Stripping it cleans the file up.

How can I tell if my text already has a BOM?

A BOM is invisible on screen but adds three bytes (EF BB BF) at the very start. This tool reports the UTF-8 byte length before and after, and tells you whether the input already begins with U+FEFF.

Does adding a BOM twice stack them?

No. The tool checks for an existing BOM first and will not add a second one, and removal strips only a single leading BOM, so the operation is safe to apply repeatedly.

What is the BOM Add / Remove Tool?

Add or remove the Unicode byte-order mark (U+FEFF, encoded EF BB BF in UTF-8) from text for BOM-sensitive applications like legacy Excel CSV import. Shows the UTF-8 byte length change so you can confirm the three BOM bytes appeared or disappeared. Runs in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

BOM Add / Remove Tool

Name: BOM Add / Remove Tool
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

The byte-order mark is a tiny, invisible character that causes outsized trouble. Some programs demand it, others choke on it. This tool lets you add or remove it precisely and confirms the change by byte count.

How it works

The BOM is the single Unicode codepoint U+FEFF. In UTF-8 it is serialised as three bytes:

EF BB BF

Adding a BOM prepends U+FEFF to the text if it is not already there. Removing a BOM strips one leading U+FEFF if present. To make the otherwise-invisible change verifiable, the tool encodes both the input and output to UTF-8 and reports the byte lengths — a difference of exactly three bytes confirms the BOM appeared or disappeared.

Why the BOM exists (and why UTF-8 is different)

The byte-order mark was designed for UTF-16 and UTF-32, where the byte order of multi-byte sequences is ambiguous. A U+FEFF at the start tells the reader whether to interpret subsequent bytes as big-endian or little-endian. A file beginning with FE FF is big-endian; FF FE is little-endian.

In UTF-8, byte order is irrelevant — every character is encoded the same way regardless of processor architecture. The BOM carries no endianness information in UTF-8 and is entirely optional. The Unicode standard itself says a UTF-8 BOM is “not recommended” but not forbidden. The result: some programs treat the BOM as a signal that the file is UTF-8; others treat it as three garbage bytes at the start of the content.

When you need to add the BOM

The clearest case is Excel CSV import. When you open a CSV file by double-clicking, Excel on Windows reads it using the system default code page (often Windows-1252) unless a BOM signals that the file is UTF-8. Without the BOM, accented characters — é, ñ, ü, ã — appear as mojibake. With the BOM, Excel recognises the encoding and displays them correctly. This matters any time you export a report containing international names, addresses, or product descriptions.

Some legacy Windows applications, notably older versions of Microsoft Access and certain older EDI platforms, also expect a BOM on UTF-8 files for similar reasons.

When you need to remove the BOM

Shell scripts — a shebang line (#!/usr/bin/env bash) must be the very first bytes in the file. A leading BOM pushes the shebang to bytes 4–N, making the kernel fail to find the interpreter.
JSON files — the JSON specification (RFC 7159 and later RFC 8259) explicitly forbids a BOM. Many JSON parsers accept it silently, but some reject it.
PHP files — a BOM before <?php sends the three bytes as output before any headers are set, which breaks header() calls and causes the “headers already sent” error.
File concatenation — if you join multiple UTF-8 files into one, any BOM on file two onwards ends up in the middle of the content rather than the start, appearing as the character (often rendered as a box or question mark).

Confirming the change

Because the BOM is invisible in plain text editors, the byte-count difference is the only reliable way to confirm it was added or removed. The tool reports the UTF-8 byte length before and after; the difference should be exactly 3. If you see 0, the BOM was already present (for add) or already absent (for remove) and no change was made.