A leading U+FEFF (Byte Order Mark) is the "bomb shelter door handle" that sometimes sticks to the front of decoded text, and BOM Remover strips exactly one such invisible code unit from position zero of a string while preserving every other character. The U+FEFF code point is the Unicode character associated with a byte order mark; at the start of a decoded text stream it acts as an encoding signature, and the UTF-8 byte form EF BB BF along with the UTF-16 and UTF-32 byte forms are simply its on-disk representations. When a parser, shebang line, JSON consumer, or column-name comparison expects the first character to be visible content, a single invisible U+FEFF is enough to break the operation. BOM Remover works because its only rule is positional: it inspects the very first UTF-16 code unit of the pasted string, returns a sliced copy from index 1 when that unit is U+FEFF, and returns the input unchanged when it is anything else. The transformation runs entirely in the current browser tab, never uploads the text, and never trims, normalizes, or globally replaces any later character.
What the "Bomb Shelter Door Handle" Really Is
The "door handle" metaphor fits because the byte order mark is a literal handle on a file's entry point: a single character your tooling grabs first when it opens the data. In Unicode that character is U+FEFF, the byte order mark, and it is the only code point that has historically been assigned both byte-order-mark and zero-width no-break space meanings. The on-disk signatures of U+FEFF are well defined. The WHATWG Encoding Living Standard describes how the UTF-8 decoder treats a leading EF BB BF sequence as a signature that produces a single U+FEFF code point in the output string, and similar rules apply to UTF-16 (FE FF or FF FE) and UTF-32 (FF FE 00 00 or 00 00 FE FF).
Once a file has been decoded, the raw bytes are gone, and the string the browser stores contains the U+FEFF code point as a single character, not as three bytes. That distinction matters because BOM Remover operates strictly on the decoded string, the same characters your <textarea> already contains. It can see whether the first code unit of that string is U+FEFF, but it cannot reconstruct which bytes the file started with or which decoder policy produced the result. Position is the entire rule.
When a Single Invisible First Character Causes Damage
Decoders vary in whether they strip a leading BOM for you, and many editors and exporters intentionally leave it in place. A few common breakages:
- Shebang lines. A shell script that begins with the bytes EF BB BF 23 21 / b i n / s h will look like it starts with a non-# character to the kernel, and the shebang will not be recognized.
- Strict JSON consumers. Some parsers reject input whose first character is not {, [, or a digit, and a leading U+FEFF triggers a parse error before the first real token is read.
- CSV column headers. When the first column of a spreadsheet is loaded, an invisible U+FEFF can merge into the first header name and cause lookups like row["id"] to silently miss the column.
- Diff and merge tools. Two files that are visually identical will be flagged as different if only one of them retains a leading BOM.
- Equality and prefix checks. A literal string such as "orders.csv" will not match a string that actually contains "\uFEFForders.csv", even when they look the same on screen.
| Scenario | Symptom from a leading U+FEFF | Why position 0 is enough to cause it |
|---|---|---|
| Shell shebang | "No such file or directory" on launch | Kernel reads the invisible char instead of # |
| JSON parser | Unexpected token or parse error at offset 0 | First code unit is not {, [, or a digit |
| CSV header lookup | Column miss or duplicate column | First header is silently prefixed with U+FEFF |
| String equality | Comparison fails for visually identical text | Literal includes the invisible code unit |
| Diff tool | Entire file marked changed | Only one side carries the signature |
These are exactly the situations where stripping the first character is correct, and where stripping every occurrence in the file would be destructive. Any U+FEFF that survives after the first character is content, not a signature, and removing it can change meaning. Readers who hit this in spreadsheet pipelines can confirm the workflow with a step-by-step guide on removing a BOM from CSV files without losing data.
Strip Exactly One Leading U+FEFF in Three Steps
BOM Remover is a deliberately narrow tool: it accepts already decoded text, inspects input.charCodeAt(0) against FEFF, and returns either a string sliced from index 1 or the exact input. To use BOM Remover on text that begins with an invisible U+FEFF:
- Paste already decoded text into the input area, including the invisible leading U+FEFF if one is present. A copy from an editor or a previously decoded file works directly; raw bytes are not accepted.
- Run the remover and read the status. The summary reports whether exactly one leading U+FEFF was removed or whether no leading U+FEFF was found, and it states the complete output length in UTF-16 code units.
- Review the complete output, including line endings and any intentional later U+FEFF content, then copy it locally. The result panel still renders when the output is empty, so an absent first character is not confused with a failed operation.
The "complete output length" number is your check that nothing else changed. If the input length was 100 UTF-16 code units and a leading U+FEFF was removed, the output length is exactly 99. The arithmetic is 100 - 1 = 99, with the one code unit removed being the only delta. If the input length and the output length are equal, no leading U+FEFF was present and the input is returned unchanged.
Edge Cases the Tool Handles on Purpose
A few inputs that look tricky are handled by explicit rules rather than by accident:
- Empty input. An empty string is a valid no-change case. The result panel still renders so the operation can be confirmed.
- Input that is only U+FEFF. The output is the empty string, and the summary reports one leading U+FEFF removed with an output length of zero.
- Two leading U+FEFF code points. The tool removes only the first and leaves the second at the beginning of the output. Running the tool a second time would remove that now-leading U+FEFF, so check the status before repeating.
- Internal or trailing U+FEFF. A U+FEFF after a line break, in the middle of a string, or at the end is preserved. The implementation does not call trim, trimStart, replaceAll, or a global regular expression.
- Line endings, tabs, NUL, emoji, combining marks, surrogate pairs, and non-Latin scripts. None of these are normalized or filtered. The copy is an exact slice of the input minus at most its first code unit.
- 200,000 code unit limit. Both the input and the output are bounded at 200,000 UTF-16 code units. An input exactly at the limit is accepted; the next code unit is rejected before processing. An input that is exactly 200,000 code units and starts with U+FEFF will be accepted (output 199,999), and an input that is 200,001 code units is rejected outright.
Editing or clearing the input immediately clears the previous output, error, summary, removal flag, copy message, and pending copy timer, so an over-limit error cannot leave an older successful result visible. Clipboard access is asynchronous and every copy receives a generation identifier, so a late permission response cannot restore stale Copied state.
What BOM Remover Will Not Do
Scope is the most important fact about this tool. The table below lists the operations it is built for and the ones it deliberately does not perform.
| Operation | Handled by BOM Remover |
|---|---|
| Check whether the first code unit is U+FEFF and slice it off | Yes |
| Preserve internal, trailing, and second-leading U+FEFF | Yes |
| Preserve CRLF, LF, tabs, NUL, emoji, and combining marks | Yes |
| Run processing and copying in the current browser tab | Yes |
| Upload the text to any external service | No |
| Detect whether the source file was UTF-8, UTF-16, or UTF-32 | No |
| Remove every U+FEFF or every zero-width character | No |
| Trim, normalize, or otherwise rewrite the rest of the string | No |
| Repair mojibake or convert raw byte sequences | No |
In short, BOM Remover is the right tool after a trusted decoder or editor has already exposed a leading U+FEFF that interferes with a parser, comparison, shebang, or column name. It is the wrong tool if the goal is to infer file encoding, convert UTF-16 bytes, validate UTF-8, repair garbled text, or strip every BOM-like character from concatenated documents. When the file load is under your control, choosing a decoder with the appropriate BOM policy is a better upstream fix than running the text through a slicer after the fact.