A BOM is the Unicode character U+FEFF that some editors and encoders prepend to text files; when those bytes are decoded into a browser textarea, the JavaScript string's first UTF-16 code unit can equal hexadecimal FEFF even though no character appears on screen. BOM Remover is a deliberately narrow tool that checks only input.charCodeAt(0) against FEFF and, on a match, returns input.slice(1), removing exactly that one code unit and nothing else. Internal, trailing, and second-leading U+FEFF characters are preserved, the transformation runs entirely in the current browser tab without uploading the text, and a 200,000 UTF-16 code unit limit applies separately to input and output. The status line reports whether exactly one leading BOM was removed or no leading BOM was found, and the result panel renders even when the output is empty so that a single-BOM input collapsing to an empty string is not mistaken for a failure. This article explains what the tool does, what it deliberately leaves alone, and when it is the right choice after a trusted decoder exposes a leading U+FEFF that interferes with a parser, shebang, or string comparison.
Bomber Side Shields vs a Text BOM: Which One Do You Mean
"Bomber side shields" usually refers to aftermarket motorcycle panels sold by brands like Bombeman and MachineartMoto that bolt to the sides of a fuel tank or engine. Those shields are physical hardware, fastened with screws or clamps, and removing them takes a Torx or hex key plus access to the bike. This article is not about that kind of shield, and no amount of pasting into a browser will help with sheet metal.
If you searched the phrase because a parser, compiler, or JSON validator keeps rejecting a file with an invisible first character, you almost certainly have a different problem: a Unicode Byte Order Mark, abbreviated BOM, sitting at position zero of your text. The two terms sound vaguely alike but share nothing in common. The first is a sheet-metal panel on a motorcycle. The second is the single Unicode code point U+FEFF that some text editors and encoders prepend to a file as a signature. Once that file is loaded into a JavaScript string, the only remaining question is whether the first code unit of that string equals FEFF.
What a Leading BOM Actually Is in a Browser Textarea
Per the WHATWG Encoding Living Standard and the Unicode Standard, a BOM is a code point at the start of a stream. The UTF-8 byte signature for the same idea is the three-byte sequence EF BB BF, while UTF-16 uses FF FE or FE FF and UTF-32 has its own equivalent. By the time those bytes pass through a decoder and arrive in a browser textarea, the bytes are already gone. What remains is a JavaScript string, and the only detectable signal is whether the first code unit equals hexadecimal FEFF.
That distinction sets a hard boundary on what a browser-based tool can know. The textarea contains decoded characters. It does not know whether the file was originally UTF-8 with an EF BB BF signature, UTF-16 LE with FF FE, UTF-16 BE with FE FF, or plain ASCII with no signature at all. BOM Remover uses that single fact as its entire rule and does not attempt to infer anything about the source file. For a deeper walk-through of the same idea in browser-side decoding, the guide on removing a leading BOM from text in your browser covers the related perspective on decoders and copy-paste workflows.
| Source signal | Bytes on disk | Visible in browser textarea as | Detectable by BOM Remover |
|---|---|---|---|
| UTF-8 with BOM | EF BB BF | Leading U+FEFF | Yes |
| UTF-16 LE with BOM | FF FE | Leading U+FEFF | Yes |
| UTF-16 BE with BOM | FE FF | Leading U+FEFF | Yes |
| UTF-32 LE with BOM | FF FE 00 00 | Leading U+FEFF | Yes |
| UTF-8 without BOM | None | First character of file | No |
| Plain ASCII | None | First character of file | No |
How to Remove Exactly One Leading BOM From Pasted Text
Use BOM Remover only after a trusted decoder or editor has exposed a leading U+FEFF that you are confident is unwanted. The tool will not warn you about edge cases; it will simply do its single, conservative action and show you the result. The full sequence is three steps.
- Paste already decoded text into the input area, including the invisible leading U+FEFF if one is present in the string.
- Run the remover and read the status line to confirm whether exactly one leading U+FEFF was removed or whether no leading U+FEFF was found.
- Review the complete output, including line endings and any intentional later U+FEFF content, then copy it locally.
Editing or clearing the input immediately clears the previous output, status, error, and clipboard state, so a stale result cannot survive a follow-up paste. If the tool reports that one leading BOM was removed, the output is the input minus its first code unit. If it reports no leading BOM found, the output is character-for-character identical to the input. Because the only action is a single slice, you can diff the input and output in another tool to confirm what, if anything, actually changed.
What BOM Remover Preserves on Purpose
The implementation deliberately does not call trim, trimStart, replaceAll, or a global regular expression on the input. That single design choice has several visible consequences worth understanding before you paste, and they all flow from one rule: position is the entire rule.
- A U+FEFF in the middle of a string stays in the middle, even if it looks like a stray signature.
- A U+FEFF after a line break is preserved as content rather than being collapsed.
- A U+FEFF at the end of the string is preserved, so trailing BOM-like characters survive the operation.
- Two consecutive U+FEFF code points at the start are handled intentionally: the first is removed as a possible signature and the second remains as initial content, because Unicode permits that pattern when a leading zero-width no-break space must be represented. Running the tool again would then remove that now-leading second U+FEFF, so always read the status before repeating the operation.
- Empty input is a valid no-change case. The result panel still renders, so the absence of visible output is not mistaken for a missing or failed run.
- Input containing only one leading U+FEFF produces a valid empty output, with the status line stating that one BOM was removed and the output length reported as zero UTF-16 code units.
Unicode guidance notes that a non-initial U+FEFF has historically carried zero-width no-break space semantics, even though U+2060 WORD JOINER is preferred for new text. Removing every occurrence would therefore be destructive, which is why BOM Remover's narrow slice is the safe default.
When Not to Use BOM Remover
The tool's narrowness is a feature, but it also defines its limits. The following tasks are explicitly out of scope and will not be solved by running BOM Remover, no matter how many times you click.
- Inferring the original file encoding from the pasted text. The textarea no longer contains bytes, so the tool sees characters only.
- Converting UTF-16 byte sequences, repairing mojibake, or validating UTF-8. The transformation is character-level only.
- Removing every BOM-like or zero-width character from a concatenated document. Only the first code unit is ever touched, one click at a time.
- Trimming trailing whitespace, normalizing CRLF or LF line endings, or applying any Unicode normalization form.
- Processing input longer than 200,000 UTF-16 code units. The next code unit beyond that limit is rejected before the transformation runs, and an over-limit error cannot leave an older successful result visible.
If you control how a file is loaded, pick a decoder or editor whose BOM policy matches your needs before pasting anything into a browser. If you have already pasted and are unsure whether the leading character is truly unwanted, read the output against the input in a diff tool before you overwrite the original. According to the WHATWG Encoding Living Standard, decoders vary in how they expose or strip a leading BOM, so the question of whether one is "wrong" almost always depends on the consumer of the text rather than on the bytes themselves.
Limits, Errors, and the Empty Output Case
Both input and output are bounded independently at 200,000 UTF-16 code units, and the boundary is enforced precisely: an input exactly at the limit is accepted, the next code unit is rejected, and the same applies to output. Because the transformation either removes zero or one code unit, a valid production input cannot expand during processing, and the separate output check exists as an explicit invariant rather than a routine guard. A failed size check clears the previous result, error, summary, removal flag, and any pending clipboard message, so a tool run cannot accidentally display an outdated output alongside a new error.
The summary line distinguishes three cases. "One leading BOM removed" appears when input.charCodeAt(0) equals hexadecimal FEFF and the output is one code unit shorter than the input. "No leading BOM found" appears when the first code unit is anything else, including empty input. The output length is reported in UTF-16 code units, which is the unit a JavaScript string uses internally and the unit that counts surrogate pairs as two. Clipboard access is asynchronous and guarded by a generation identifier, so a late permission response cannot restore stale Copied state, and a denied request leaves the full read-only output available for manual selection.