BOM stripper
What the BOM stripper does
The byte-order mark is U+FEFF, an invisible character some tools plant at the very start of a text file to flag how it's encoded. It renders as absolutely nothing, so a file with one looks completely normal in an editor while still carrying an extra character no one can see.
This app removes it, wherever it sits in the text, along with the zero-width spaces, joiners and soft hyphens that tend to travel the same routes. It's local: everything runs in your browser, nothing you paste is uploaded, and there's no limit on how much you clean or how often you're back.
For a debugging tool specifically, that local-only guarantee matters. You're usually pasting in something broken because of a character you can't see, and the last thing you want is a second layer of not-knowing what happened to it once it left your machine.
Workflow
How to remove a byte-order mark in three steps
A BOM is invisible by definition, so there's nothing to eyeball first.
- Step 1
- Paste the file's contents in, including the very first character.
- Step 2
- Press Remove. It runs instantly, on your device.
- Step 3
- Copy the cleaned text back into your file or import.
The character itself
What U+FEFF is, and why anything writes it
UTF-16 files can store their bytes in either order, and a byte-order mark up front tells a reader which order was used. UTF-8 doesn't actually need that signal at all, its byte order is fixed regardless, but a handful of tools, Windows Notepad chief among them, write a UTF-8 byte-order mark anyway as a kind of explicit encoding flag.
That's the entire origin story of most of these bugs: software meaning to be helpful by tagging a file's encoding, and other software reading that tag as the first character of real content instead of as metadata to skip.
Why it matters
What a byte-order mark breaks in CSV, JSON and scripts
In a CSV file, a leading BOM fuses onto the first column header. A column that's clearly named id in the editor gets read as an entirely different string by a strict parser, so any code checking for a header called id comes up empty, and the failure looks nothing like an encoding problem.
In JSON, a leading BOM isn't valid syntax at all. A strict JSON.parse call rejects the whole file, with an error message that says nothing about the invisible character actually responsible. In a shell script, a BOM sitting before the shebang line stops the OS from recognising #!/bin/bash as the interpreter directive, so the script fails to run in a way that looks like anything but an encoding bug.
The usual sources
Where a stray BOM usually comes from
Saving a file as 'UTF-8' out of Notepad on Windows writes one by default. Certain Excel export paths for UTF-8 CSV do the same. A handful of other Windows tools follow suit, on the logic that flagging the encoding explicitly is safer, even though virtually everything downstream assumes UTF-8 without being told.
The file passes every visual inspection along the way. It opens cleanly, looks right, and only fails once it reaches something that treats the BOM as data rather than metadata to skip.
Not just position zero
This checks the whole document, not just the first character
A BOM causes the most damage at the very start of a file, but it's not exclusively a start-of-file problem. Concatenating several files, a bad merge, or a paste from a source that already had one embedded partway through can leave a byte-order mark, or a zero-width space, sitting mid-document. This app scans the full text, not just the first position, and removes every hidden character it finds.
Who it's for
Who uses a BOM stripper, and when
Developers chasing a CSV import that silently fails to match a header, or a JSON.parse that throws on a file that looks completely valid in the editor, both land here. Teams maintaining shell scripts edited on Windows use it to rule out a leading BOM as the cause of a cryptic interpreter error.
It's also a habit before committing a config file or a data export: a stray BOM at the top of a file is exactly the kind of thing a code review scans right past.