BOM stripper

The byte-order mark, U+FEFF, is a single invisible character that some tools write at the start of a text file to indicate its encoding. It renders as nothing, so a file carrying one passes every visual inspection, and still fails the moment it reaches a parser that treats the mark as content rather than metadata.

This tool removes it, along with a small set of related hidden characters, entirely client-side. Nothing is uploaded, so there is nothing to log or queue, which is also why there is no run limit.

A BOM is invisible by definition, so there's nothing to verify visually before running this.

Step 1

Paste the file's contents into the input field, including the first character.

Step 2

Run the removal. It executes instantly, locally.

Step 3

Read the result and return it to the file, import or script.

UTF-16 text can store its bytes in either order, and a byte-order mark at the start of a file specifies which order was used. UTF-8's byte order is fixed regardless of any such marker, so it does not require one, but several tools, Windows Notepad prominent among them, write a UTF-8 byte-order mark anyway as an explicit encoding flag.

That decision is the origin of most of the downstream bugs: software tagging a file's encoding for safety, and other software downstream reading that tag as the first literal character of the file's actual content.

In CSV, a leading BOM fuses onto the first column header. A header that reads as id in a spreadsheet is read as a different string entirely by a strict parser, so code checking for a header literally named id fails to find it, with no error that points at encoding as the cause.

In JSON, a leading BOM is invalid syntax outright. A strict JSON.parse call rejects the file wholesale, with an error message that gives no indication the actual fault is one invisible character. In a shell script, a BOM preceding the shebang line prevents the operating system from recognising the interpreter directive, so execution fails in a way that reads as unrelated to encoding entirely.

Saving a file as UTF-8 from Windows Notepad writes one by default. Certain Excel export paths for UTF-8 CSV do the same. A handful of other Windows-native tools follow the same convention, on the premise that an explicit encoding flag is safer than an implicit one, though most modern software assumes UTF-8 without needing to be told.

The resulting file passes every visual inspection along the way: it opens cleanly and reads correctly, right up to the point where it meets a parser that treats the mark as data instead of metadata.

A byte-order mark causes the most visible damage at the start of a file, but concatenating several files, a rough merge, or a paste from a source that already carried one mid-document can leave it, or a zero-width space, sitting anywhere in the text. This tool checks the entire document rather than only the leading position, and removes every hidden character it detects.

Engineers debugging a CSV import that silently fails to match a column name, or a JSON.parse call throwing on a file that reads as valid in an editor, use this to rule out an encoding cause quickly. Teams maintaining shell scripts edited on Windows use it to check for a leading BOM before assuming a more complex bug.

It's also a routine check before committing a config file or a data export, since a stray byte-order mark at the top of a file is precisely the kind of defect a code review scans past without noticing.