Skip to content
Lizely

BOM Remover

Remove exactly one leading U+FEFF from pasted decoded text locally while preserving every internal, trailing, or second leading occurrence.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Paste already decoded text, including the invisible leading U+FEFF if one is present.
  2. 2.Run the remover and read the status to confirm whether exactly one leading U+FEFF was removed.
  3. 3.Review the complete output, including line endings and any intentional later U+FEFF content, then copy it locally.

About BOM Remover

BOM Remover is a deliberately narrow text tool. It checks whether the first UTF-16 code unit of the pasted JavaScript string is U+FEFF. If it is, the tool removes exactly that one code unit. If the first code unit is anything else, the output is identical to the input. Processing and copying happen in the current browser tab, and the text is not uploaded to Lizely or sent to an external service.

U+FEFF is the Unicode character associated with a byte order mark. At the beginning of a decoded text stream it can represent an encoding signature. The UTF-8 byte signature is EF BB BF, while UTF-16 and UTF-32 have their own byte signatures. This interface does not inspect any of those raw bytes. A browser textarea already contains decoded characters, so the tool can only see whether the resulting string begins with the U+FEFF code point. It cannot identify the original file encoding, byte order, decoder behavior, or whether a source file once contained a particular byte sequence.

Position is the entire rule. The implementation does not call trim, trimStart, replaceAll, or a global regular expression. A U+FEFF in the middle of a string is preserved. A U+FEFF after a line break is preserved. A U+FEFF at the end is preserved. Unicode guidance explains that a non-initial U+FEFF has historically carried zero-width no-break space semantics and is part of content, even though U+2060 WORD JOINER is preferred for new text. Removing every occurrence would therefore be destructive.

Two consecutive U+FEFF code points at the start are handled intentionally. Unicode describes the first as the possible signature and the second as an initial content character when a leading zero-width no-break space must be represented. BOM Remover removes the first code unit and leaves the second at the beginning of the output. Running the tool again would remove that now-leading second U+FEFF, so review the status before repeating the operation. One click never removes more than one code unit.

Empty input is a valid no-change case. Input containing only one leading U+FEFF produces a valid empty output. The result panel still renders when output is empty, so the absence of visible characters is not confused with a failed operation. The summary states whether one leading U+FEFF was removed or no leading U+FEFF was found, and it reports the complete output length in UTF-16 code units.

All remaining text is copied by an exact slice operation. CRLF and LF line endings, tabs, NUL, emoji, combining marks, surrogate pairs, non-Latin scripts, whitespace, and later U+FEFF occurrences are not normalized or filtered by the transformation. A browser may visually normalize how some invisible characters appear in a textarea, but the JavaScript string produced by the logic is the original string minus at most its first U+FEFF code unit. This is not a general invisible-character cleaner, Unicode normalizer, whitespace trimmer, or encoding repair service.

Input may contain at most 200,000 UTF-16 code units, and output has an independent 200,000-code-unit limit. An input exactly at the limit is accepted. The next code unit is rejected before processing. Output validation accepts the exact boundary and rejects boundary plus one. Nothing is shortened, sampled, partially returned, or silently prevented by an HTML maxLength. Because this transformation only removes zero or one code unit, a valid production input cannot expand during processing; the separate output check remains an explicit invariant and executable test boundary.

Editing or clearing the input immediately clears the previous output, error, summary, removal flag, copy message, and pending copy timer. An over-limit error cannot leave an older successful result visible. Clipboard access is asynchronous, so every copy receives a generation identifier. Editing, clearing, retrying, or unmounting invalidates that generation. A late clipboard permission response cannot restore stale Copied state, and a denied request leaves the full read-only output available for manual selection.

Use BOM Remover after a trusted decoder or editor exposes a leading U+FEFF that interferes with a parser, comparison, shebang, column name, or other first character. Do not use it to infer file encoding, convert UTF-16 bytes, validate UTF-8, repair mojibake, remove arbitrary zero-width characters, or strip every BOM-like character from concatenated documents. If you control file loading, choose a decoder with the appropriate BOM policy; if you paste text here, verify that the leading U+FEFF is truly unwanted before copying the result over an original.

Methodology & sources

Accept already decoded text up to 200,000 UTF-16 code units, including the empty string. Test only input.charCodeAt(0) against hexadecimal FEFF. If it matches, return input.slice(1); otherwise return the exact input string. Never trim, normalize, scan, or globally replace later content. Validate complete output at or below 200,000 code units and return a separate removed boolean plus input and output lengths. Clear result, error, removal status, and asynchronous clipboard state on every edit or clear action. Guard clipboard completion and its timer with generation and mounted-state checks. Executable tests cover leading, absent, internal, trailing, doubled-leading, BOM-only, empty, CRLF, post-CRLF, emoji and accented text, several internal positions, and exact plus-one input and output budgets.

Frequently asked questions

Does this remove every BOM or zero-width character?
No. It removes at most one U+FEFF and only at string position zero. Internal, trailing, and second-leading U+FEFF characters remain unchanged, and other invisible characters are outside scope.
Can it detect whether a file is UTF-8, UTF-16, or UTF-32?
No. Pasted textarea content is already decoded. The tool sees characters, not the original EF BB BF, FE FF, FF FE, or other raw byte signatures.
What happens when two U+FEFF characters are at the start?
Only the first is removed. The second remains at the beginning of the output because Unicode permits it to represent initial content after a BOM.
Why is an empty output still shown as a result?
A text consisting only of one U+FEFF correctly becomes empty. The result panel and summary distinguish that successful transformation from a missing or failed result.

Related tools

Developer Tools guides

View all