BOM stripper
What the BOM stripper does
A byte-order mark is a single invisible character, U+FEFF, that some tools write at the very start of a text file to signal how it's encoded. It renders as nothing, so opening the file in most editors shows nothing wrong, but the character is still there, sitting in front of everything else in the document.
This tool removes it wherever it appears, along with the small set of other hidden characters that travel the same routes: zero-width spaces, joiners and soft hyphens. Paste your text, remove it, copy the result. It runs in your browser, with nothing uploaded and no limit on how much you clean.
How it works
How to remove a byte-order mark in three steps
A BOM at the front of a file is invisible, so there's nothing to check by eye before you run this.
- Step 1
- Paste the text, including the very first character, into the box.
- Step 2
- Press Remove. It runs instantly, on your own device.
- Step 3
- Copy the result and save or paste it where it needs to go.
The character
What U+FEFF actually is, and why it exists
UTF-16 text can be stored with its bytes in either order, and a byte-order mark at the start of the file tells a reader which order was used. UTF-8 doesn't need that signal, since its byte order is fixed either way, but some tools, notably Windows Notepad and certain export routines, write a UTF-8 byte-order mark anyway, as a kind of 'this file is UTF-8' flag.
That flag is where the trouble starts. A BOM is not a printable character; it's metadata that some software understands and strips automatically, and other software reads as the first literal character of the file's actual content.
Why it matters
What a byte-order mark actually breaks
A BOM at the start of a CSV file glues itself onto the first column header, so a column literally named id gets read by a strict parser as a completely different string, and any code checking for a header called id fails to find it. In JSON, a leading BOM is not valid syntax at all, and a strict parser rejects the entire file with an error that gives no hint the actual problem is one invisible character.
In a shell script, a BOM before the shebang line stops the operating system recognising #!/bin/bash as the interpreter directive it's supposed to be, so the script fails to execute with an error that looks nothing like 'there's an invisible character at the top of your file'.
Where it comes from
Why files end up with a BOM in the first place
Saving a plain text file as 'UTF-8' from Notepad on Windows writes a BOM by default. Excel does the same thing when it exports certain files as UTF-8 CSV. Several other Windows-native tools follow the same convention, on the reasoning that an explicit encoding flag is safer than an implicit one, even though most modern software assumes UTF-8 without needing to be told.
The result is that a file can pass every visual check, open cleanly, look completely normal, and still fail the moment it reaches a parser that treats the byte-order mark as data instead of metadata.
Not just at the start
This tool checks the whole text, not only the first character
A byte-order mark most commonly causes trouble sitting at the very start of a file, but the same invisible character, along with zero-width spaces, joiners and soft hyphens, can end up anywhere in a document through concatenation, a bad merge of several files, or a copy-paste from a source that already had one embedded mid-document. This tool scans the entire text, not just the first character, and removes every hidden character it finds.
Who uses it
Who uses a BOM stripper, and when
Developers debugging a CSV import that silently fails to match a column name, or a JSON.parse call that throws on a file that looks perfectly valid in an editor, both end up here. Anyone writing or maintaining shell scripts that were edited on Windows and now fail with a cryptic interpreter error uses it to rule out a leading BOM.
It also comes up before committing a config file or a data export to a repository, since a stray BOM at the top of a file is exactly the kind of thing a code review misses on sight.