A bommer is a phonetic misspelling of BOM, the Unicode U+FEFF byte order mark that can appear as an invisible first character in decoded text. To remove a bommer cleanly, paste your already-decoded text into BOM Remover, which checks only the first UTF-16 code unit of the pasted string and removes exactly one U+FEFF if it sits at position zero. The tool then reports whether a leading bommer was found, returns the complete output with all internal and trailing U+FEFF characters preserved, and copies the result locally without uploading the input to any service. Processing happens entirely in your current browser tab, so the original file encoding, raw byte sequence, and decoder behavior are not visible to the tool — only the decoded JavaScript string produced by your textarea is examined. That strict, position-only rule is what makes BOM Remover safe to use on JSON, CSV, shell scripts, SQL dumps, configuration files, and any other text where a stray invisible character at the start would corrupt a parser, a shebang, a column name, or a string comparison.
What "bommer" actually means in a text file
The word "bommer" does not exist in the Unicode standard or in any encoding specification. In practice, it appears in search queries and support tickets as a phonetic spelling of BOM, the byte order mark, which Unicode assigns to the code point U+FEFF. The character is invisible in most editors, has zero advance width when rendered alone, and often arrives at the start of a text stream when a decoder honors a byte signature such as EF BB BF for UTF-8 or FE FF or FF FE for UTF-16. Because the character never paints a glyph of its own, users see a broken first line, a parser that throws on the first character, or a string comparison that mysteriously fails, and they describe the symptom with whatever word happens to come to mind — "bommer", "bommer spring hinge", "bommer side shield", or simply "invisible first character".
Unicode guidance explains that U+FEFF at the start of a stream is a permitted signature, and that a non-initial U+FEFF has historically carried zero-width no-break space semantics, which is why the same code point can mean two different things depending on where it appears. The preferred code point for new zero-width joining content is U+2060 WORD JOINER, but the older U+FEFF behavior persists in real text. That double meaning is the reason a generic "remove every invisible character" pass is destructive, and the reason a position-aware tool is the right shape for the job.
Why a leading U+FEFF breaks parsers and comparisons
A single U+FEFF at the start of decoded text will silently invalidate anything that expects the first character to be a real letter, digit, symbol, or line break. JSON parsers reject input whose first decoded character is not whitespace, an array bracket, or an object brace. CSV importers built on strict RFC 4180 assumptions can shift the first column header by one character so that the file appears to have an empty leading column. Shell scripts with a shebang fail when the first three bytes are EF BB BF (the UTF-8 BOM), so the interpreter looking for '#!' at byte offset 0 never finds the shebang line. SQL loaders, YAML emitters, XML processors, and Heredoc-aware tools all share the same blind spot: the first character is special, and an invisible one is the worst kind of special.
String comparisons suffer the same fate. A "starts with" check, a sorted list, a dedupe key, and a primary-key lookup can all treat two otherwise identical strings as different because one of them begins with U+FEFF. The bug is rarely visible until someone pastes the same value from two sources and notices the deduplication is off by one. Removing the bommer at the start is the only safe fix, and only when you can prove the leading character really is unwanted.
Remove a bommer with BOM Remover
The verified workflow for removing a bommer from pasted decoded text is intentionally short. Each step uses a single browser interaction, and the tool exposes the result in plain characters so you can audit it before copying.
- Paste already decoded text into the input area, including the invisible leading U+FEFF if one is present. The tool works on the decoded JavaScript string produced by the textarea, so do not paste raw bytes and expect byte-level detection.
- Run the remover and read the status line. The summary explicitly states whether exactly one leading U+FEFF was removed or whether no leading U+FEFF was found, and it reports the complete output length in UTF-16 code units.
- Review the entire output, including line endings and any intentional later U+FEFF content. The result panel renders even when output is empty so that a successful BOM-only removal is not confused with a failed operation.
- Copy the cleaned text locally using the in-page copy control. The clipboard write is guarded by a generation identifier so a late or denied permission response cannot leave stale "Copied" state behind, and the full read-only output remains available for manual selection.
If your input contains two consecutive U+FEFF code points at the start, BOM Remover removes only the first; the second remains at the beginning of the output because Unicode permits it to represent an initial zero-width no-break space. Running the tool again on the result would then remove that now-leading second U+FEFF, so always re-read the summary before repeating the operation.
Rules BOM Remover enforces on the result
BOM Remover is deliberately narrow, and that narrowness is what makes the output trustworthy. The implementation does not call trim, trimStart, replaceAll, or a global regular expression on your input. It only checks input.charCodeAt(0) against the hexadecimal value FEFF and, on a match, returns input.slice(1). When the first code unit is anything else, the returned string is the exact input string with no changes. As a consequence, every other character in your text — including CRLF and LF line endings, tabs, NUL bytes, emoji, combining marks, surrogate pairs, non-Latin scripts, and any later U+FEFF occurrence — survives byte-for-byte. Editing or clearing the input immediately clears the previous output, the error, the summary, the removal flag, the copy message, and any pending copy timer, so an over-limit error cannot leave an older successful result visible on screen.
The separate output validation enforces a hard ceiling: input may contain at most 200,000 UTF-16 code units and output has an independent 200,000-code-unit limit. Because the transformation only removes zero or one code unit, a valid production input cannot expand during processing, and the output check remains an explicit invariant and executable test boundary. An input exactly at the limit is accepted; the next code unit is rejected before processing. Nothing is shortened, sampled, or partially returned, and nothing is silently prevented by an HTML maxLength attribute.
What BOM Remover will not do
Position is the entire rule, and several reasonable-sounding tasks are explicitly outside scope. BOM Remover cannot infer the original file encoding from pasted text, because a browser textarea already contains decoded characters, and the tool can only see whether the resulting string begins with U+FEFF. It cannot tell you that the source file once contained EF BB BF, FE FF, or FF FE; those byte signatures are gone by the time the text reaches the tool. It will not convert UTF-16 bytes, validate UTF-8, repair mojibake, or strip arbitrary zero-width characters such as U+200B, U+200C, U+200D, or U+2060. It will not strip every BOM-like character from a concatenated document, because removing every internal U+FEFF would silently delete content the Unicode standard says is part of the text.
If you control file loading, the correct first step is to choose a decoder with the appropriate BOM policy — many JSON and CSV readers expose a switch — rather than to paste the file's decoded content here. If you paste text into BOM Remover, verify that the leading U+FEFF is truly unwanted before copying the result over an original, because the slice operation is exact and irreversible in the output buffer. For a broader, file-oriented workflow you can compare this approach with how to remove a leading BOM from text in your browser, which describes the same position-only rule in a file-paste context.
BOM Remover versus general text-cleaning approaches
Many general-purpose text utilities will gladly strip every U+FEFF they find, every zero-width character they recognize, or every byte in the EF BB BF range from the first three positions. Those behaviors sound helpful until they collide with content that legitimately contains a non-initial U+FEFF as a zero-width no-break space. The comparison below summarizes how a position-only remover differs from a global cleaner along the axes that matter for safe text editing.
| Behavior | BOM Remover (position-only) | Global invisible-character cleaner |
|---|---|---|
| Maximum U+FEFF characters removed | Exactly one, and only at index 0 | Every occurrence in the string |
| Internal U+FEFF preserved | Yes, byte-for-byte | No, removed as part of a global pass |
| Trailing U+FEFF preserved | Yes | Usually no |
| Two consecutive leading U+FEFFs | Removes the first, leaves the second at position 0 | Removes both |
| Other zero-width characters (U+200B, U+200C, U+200D, U+2060) | Outside scope, untouched | Usually stripped |
| Network upload | None, runs in the current tab | Depends on the tool |
| Input and output size limit | 200,000 UTF-16 code units, checked separately | Varies, often implicit |
The two columns describe different contracts. Use BOM Remover when the leading U+FEFF is the only character you suspect and you want every other byte preserved. Use a global cleaner only when you have independently confirmed that your text contains no legitimate zero-width no-break spaces, no legitimate internal U+FEFF, and no concatenated documents where the same character carries different meanings in different sections. For an alternative paste-and-clean path that emphasizes file-level rather than character-level inspection, the local-in-browser guide at how to remove a BOM from a file locally in your browser walks through the same JavaScript lexical grammar boundaries referenced in the BOM Remover implementation, and how to strip exactly one leading BOM from pasted text restates the position-only rule for a slightly different starting point.
Practical checks before and after
Before you paste, confirm that your decoder did not silently strip a bommer for you — some loaders honor a UTF-8 signature and remove it transparently, in which case BOM Remover will report no leading U+FEFF found and the output will equal the input. After you copy, confirm that the cleaned text still parses in the destination tool, and compare the reported output length against your expectation: if your input was a single U+FEFF, a valid output is empty and the result panel will still render with a length of zero. If your input had two leading U+FEFFs, the output will still begin with one U+FEFF, which is correct under the Unicode rule that treats the second code point as initial content. If you need to remove that second character as well, paste the result back into the tool and run it once more — the summary will tell you a second leading U+FEFF was removed, and you can decide whether to stop there or treat the remaining character as content.
For browser-side confirmation that the removed character really was U+FEFF and not a visually similar zero-width space, the MDN JavaScript lexical grammar reference documents how a JavaScript string treats U+FEFF as a whitespace code point, BOM Remover instead uses an exact position-zero check and does not apply that whitespace rule to following characters. The WHATWG Encoding Living Standard at encoding.spec.whatwg.org describes how decoders interact with byte signatures, which is the upstream layer where a bommer originally enters a text stream. Together, those references explain why the tool inspects characters rather than bytes and why it cannot infer the original encoding from a pasted textarea.