A BOM Remover is a browser-based tool that removes exactly one leading U+FEFF byte order mark from a pasted, already-decoded text snippet while preserving every other character, including any internal, trailing, or second-leading U+FEFF occurrences. It identifies the BOM by checking whether the first UTF-16 code unit of the pasted JavaScript string equals U+FEFF (hexadecimal FEFF), and if so, returns the input minus that one code unit using an exact slice operation. The implementation deliberately avoids trim, normalize, scan, or global replace, so an unwanted BOM at position zero is removed but every other character stays in place, including CRLF and LF line endings, tabs, emoji, combining marks, surrogate pairs, non-Latin scripts, and any later zero-width characters. Processing happens entirely in the current browser tab, the text is not uploaded to any external service, and the tool reports whether a leading BOM was actually removed or whether the input was already clean. This makes it a precise, predictable option when you need to strip a leading BOM from a file without risking damage to the rest of the content.
Why a Leading BOM Breaks Some Files
After a UTF-8, UTF-16, or UTF-32 file is decoded into a string, the very first character is sometimes a U+FEFF code point. That character is the Unicode byte order mark, and it serves a legitimate purpose at the start of a byte stream as an encoding signature. According to the WHATWG Encoding Living Standard, decoders may consume a BOM before any user-visible content, but they may also pass it through unchanged to the caller. When a decoder passes it through, that U+FEFF becomes part of the decoded text and shows up in position zero.
From that point onward, the invisible BOM can interfere with anything that treats the first character as content:
- JSON parsers that reject non-whitespace characters before the first token refuse a string that begins with U+FEFF.
- Shell scripts with a shebang line fail because the first two bytes are the BOM, not the "#!" sequence.
- CSV column names line up incorrectly when a BOM is treated as part of the first header, because the first column ends up named "\uFEFFid" instead of "id".
- String comparisons and equality checks return false even when the visible characters match, because the first code unit is different.
- Markdown, XML, and templating engines can render the BOM as a visible artifact or shift rendered output by one character.
The standard remedy is to strip that single leading code unit before the rest of the file is processed. BOM Remover is built for exactly that remedy and for nothing else, so it does not blur the line between BOM removal and broader cleanup.
How to Remove BOM from a File Using BOM Remover
The tool works on already-decoded text. Anything you paste into its textarea is treated as a JavaScript string, not as raw bytes, so the leading U+FEFF must already be visible to the browser as a character at position zero. The full operation is straightforward.
- Open the file in an editor or terminal and copy its decoded contents. A plain text editor that respects the file's encoding works well. If you copy through a clipboard that strips zero-width characters, paste into a tool that exposes them first, then recopy.
- Paste the text into the BOM Remover textarea. The invisible U+FEFF at the start, if present, is included as the first code unit of the string. The browser does not display it, but the JavaScript string still begins with it.
- Run the remover and read the status line. The summary states whether exactly one leading U+FEFF was removed, or whether no leading U+FEFF was found in the input. The output length, in UTF-16 code units, is reported next to the input length.
- Review the complete output, including line endings and any intentional later U+FEFF content. The result panel renders the full output exactly as it will be copied, so CRLF sequences, tabs, and any non-initial U+FEFF characters remain visible for inspection.
- Copy the result locally and save it back to the file. Clicking the copy control uses an exact slice operation, so the value placed on the clipboard matches the visible output character for character. Paste it back into your editor and save under the same name.
If the status message reports that no leading U+FEFF was found, the input did not begin with that code unit and the output is identical to the input. There is nothing to remove and the file is already clean at position zero.
Input Format, Limits, and What the Status Tells You
Because the tool operates on a JavaScript string in a browser, it cannot see file bytes or original encoding. It can only see the decoded characters in the textarea. That choice has two practical consequences for working with files.
First, the maximum size is 200,000 UTF-16 code units for both input and output. An input exactly at the limit is accepted; the next code unit is rejected before processing begins. UTF-16 code units are not the same as bytes, and supplementary characters encoded as surrogate pairs count as two code units. The output has its own independent 200,000-code-unit limit, and since the transformation only removes zero or one code unit, a valid input cannot grow during processing. The boundary check is still enforced as an explicit invariant.
Second, the status message is the source of truth for what happened. It distinguishes three cases:
- One leading U+FEFF was removed. The input began with U+FEFF and the output is exactly one code unit shorter.
- No leading U+FEFF was found. The input did not begin with U+FEFF and the output is character-for-character identical to the input.
- Input over the limit. The input or output would exceed 200,000 code units and processing did not run.
Editing or clearing the input immediately clears the previous output, error, summary, removal flag, copy message, and pending copy timer. That means an over-limit error cannot leave an older successful result behind, and a stale clipboard notice cannot survive a retry. Because clipboard access is asynchronous, every copy action receives a generation identifier, and a late permission response cannot restore a stale Copied state. A denied request leaves the full read-only output available for manual selection.
Common File Cases and How the Tool Handles Them
The transformation is deliberately narrow, so the behavior for each kind of file content is fixed and predictable. The table below summarizes the common cases you will encounter when cleaning a file.
| Input pattern | What BOM Remover does | Output vs input length |
|---|---|---|
| Starts with a single U+FEFF | Removes the first code unit only | One code unit shorter |
| Starts with two U+FEFF | Removes the first; the second becomes the new first code unit | One code unit shorter |
| Does not start with U+FEFF | No change, output is identical to input | Same length |
| Empty string | No change, output is an empty result panel | Same length (0) |
| Input is exactly one U+FEFF | Removes it, output is empty but still rendered | Zero (was 1) |
| U+FEFF after a line break, in the middle, or at the end | No change at position zero, all later U+FEFF preserved | Same length |
Two of these cases are worth calling out. First, an empty output is a valid result, not a failure. A file that contained only a BOM becomes an empty string after the removal, and the result panel still renders so the absence of visible characters is never confused with a missing operation. Second, Unicode permits a non-initial U+FEFF to carry zero-width no-break space semantics and be part of the content. The tool preserves those positions on purpose, even though the Unicode Standard now recommends U+2060 WORD JOINER for new text. Removing every occurrence would be destructive, and the implementation does not call trim, trimStart, replaceAll, or a global regular expression.
What BOM Remover Will Not Do
The tool is scoped to one narrow operation, and several related tasks fall outside that scope on purpose. Knowing what it does not do is just as important as knowing what it does.
- It does not detect file encoding. The textarea sees decoded characters, not raw bytes like EF BB BF, FE FF, or FF FE. There is no way to recover the original encoding from a pasted string.
- It does not remove every BOM-like character. Only one leading U+FEFF is removed per run. Internal, trailing, and second-leading U+FEFF characters remain in the output.
- It does not normalize whitespace, line endings, or Unicode forms. CRLF stays CRLF, LF stays LF, tabs and NUL are not modified, and no NFC or NFKC normalization is applied.
- It does not repair mojibake or fix misdecoded content. Garbled characters from a wrong encoding are not detected or corrected.
- It does not upload or transmit your file content. Everything happens in the current browser tab, and the clipboard write is local.
If you control the file-loading step, the right place to deal with a BOM is the decoder. Many libraries accept a BOM policy flag that lets the consumer choose whether to consume the BOM or pass it through. Pasting into BOM Remover is appropriate when an upstream tool already exposed an unwanted leading U+FEFF and you need to clean it before the next step in a pipeline. Before copying the cleaned result over an original file, verify that the leading U+FEFF was truly unwanted, because the same character can also be deliberate content.
For a deeper walkthrough of the underlying string rules, the MDN JavaScript lexical grammar reference documents how source text is interpreted, including the handling of whitespace-like characters at the start of a script. The WHATWG Encoding Living Standard covers how decoders expose a BOM to the caller or consume it transparently, which is the original source of the leading U+FEFF situation this tool addresses.