BOM Remover removes exactly one leading U+FEFF code unit from decoded text — no more, no less, and only when that single character sits at position zero. In this article, BOM refers to the Unicode character U+FEFF (the byte order mark) that often rides at the start of plain-text fragments — reports copied from SAP GUI, ALV exports, spool dumps, or any other text feed that wrote a UTF-8, UTF-16, or UTF-32 byte signature before the first real character. The same three letters in SAP also abbreviate Bill of Materials, a master-data object maintained through production-planning transactions and entirely unrelated to this guide. Readers searching for the SAP Bill of Materials side should look at procurement- or engineering-documentation paths instead; readers with a leading U+FEFF that breaks a JSON parser, SQL loader, shebang, or column-name comparison will find every step they need below. The BOM Remover tool runs entirely in the current browser tab, never uploads the pasted string, and treats position as the entire rule.
What BOM Means in This Guide
In Unicode, the abbreviation BOM refers to the byte order mark, a single character at code point U+FEFF whose visible glyph is empty but whose presence marks a decoded string as having begun with an encoding signature. The byte signatures differ by encoding: UTF-8 files start with the three-byte sequence EF BB BF, UTF-16 with FE FF or FF FE depending on byte order, and UTF-32 with the analogous 32-bit markers. Once a decoder turns those bytes into characters, the only thing left in the string is one invisible U+FEFF at position zero. The same three letters in SAP stand for Bill of Materials, a master-data row maintained inside production-planning modules; that semantic lives in dedicated SAP transactions and is unrelated to this tool.
For the rest of this article, every reference to BOM means the U+FEFF character — a single invisible code point that survives decoding but can derail downstream tooling that expects the first character to be a real letter, digit, quote, or shell marker.
Why a Leading U+FEFF Breaks Your Pipeline
The trouble with a leading U+FEFF is that almost nothing prints, logs, or counts it. You copy what looks like the string NAME,VALUE, paste it into a diff checker, and the diff claims the first column is missing because U+FEFF sits invisibly in front of NAME. A handful of failure patterns recur across stacks:
- JSON parsers such as JavaScript's JSON.parse reject the input with an "Unexpected token" error that points at column 1, even though the first visible character is a quote.
- CSV readers expose the BOM as a column name whose first row reads "\uFEFFheader_one" instead of "header_one", which then breaks SQL SELECT statements that quote the column. For CSV-specific export pipelines, the Remove BOM from CSV Files Without Losing Data workflow walks the same rule end-to-end.
- Shebang lines such as #!/usr/bin/env python stop being shebangs once U+FEFF sits in front of the hash, and POSIX kernels refuse to execute the file.
- String equality checks between two files that "look identical" fail because one starts with U+FEFF and the other does not, which wastes time in code review and in diff tooling.
- Shell while read loops treat the BOM as part of the first field's name, leaving a stray invisible character that breaks awk field separators downstream.
Each of these failures comes from the same root cause: position zero is not what the consumer expected. Fixing the string at the decoder is the clean answer; stripping the already-decoded character in a controlled way is the second-best answer, and BOM Remover is built for exactly that second case.
How BOM Remover Decides What to Delete
BOM Remover's logic is narrow on purpose. As described in MDN's JavaScript lexical grammar reference, charCodeAt(0) returns the integer value of the first UTF-16 code unit, which is how the tool's only test lands inside the page. The tool asks whether that first value equals 0xFEFF. If it does, the tool returns input.slice(1) — the original string with that single code unit removed. If the first unit is anything else, the tool returns the exact input string unchanged. There is no trimming, no normalization, no global regex, no replaceAll, and no scan of later positions.
This narrow rule produces three deliberate consequences the source material calls out explicitly:
- A U+FEFF inside the string is content. According to Unicode guidance, non-initial U+FEFF historically carried zero-width no-break space semantics, and the modern preference for that role is U+2060 WORD JOINER. Stripping every occurrence would destroy legitimate content, so the tool deliberately leaves internal and trailing U+FEFF alone.
- A U+FEFF after a line break is content. The tool never collapses or repositions line endings, so a CRLF-then-U+FEFF sequence still contains a leading U+FEFF on the next line — exactly the kind of internal content the rule is designed to skip.
- Two leading U+FEFF code points are not the same as one. Unicode treats the first as a possible encoding signature and the second as ordinary initial content. BOM Remover removes only the first; the second slides into position zero and stays there until you run the tool again. Read the summary before repeating the operation.
The implementation is intentionally short because every additional check would either broaden the scope beyond a single character or risk mutating legitimate invisible content elsewhere in the string.
How to Use BOM Remover Step by Step
The full workflow fits in three actions, and every step happens in the current browser tab. Open the BOM Remover tool, paste your string, and follow the order below.
- Paste the already-decoded text into the input area. Copy the fragment from your SAP GUI window, ALV export, log file, terminal, or any other source and paste it in full, including the invisible leading U+FEFF if one is present. A browser textarea holds decoded characters, not raw bytes, so the tool only sees the decoded form.
- Run the remover and read the status field. The status tells you whether exactly one leading U+FEFF was removed or whether no leading U+FEFF was found. It also reports the complete output length in UTF-16 code units, which lets you confirm that nothing internal was silently touched.
- Review the full output, then copy it locally. Read the result panel end-to-end — line endings, internal U+FEFF content, trailing invisible characters, emoji, surrogate pairs, combining marks, and all. When you are sure the transformation did what you intended, copy the result back into the target file, editor, or pipeline. If the platform refuses the clipboard write, the read-only output is still selectable for manual copying.
If you run the tool a second time on the same output, you remove the second-leading U+FEFF the first run left behind. Two runs on a string that began with two U+FEFF characters produce the same final string as if you had stripped both at once, but the tool never does both in one click.
What BOM Remover Preserves and What It Removes
The position rule produces eight distinct scenarios, each with a clear and predictable result. The table below summarizes every case the source material enumerates, so you can match your own input against it before you click.
| Input starts with | Output | Why |
|---|---|---|
| U+FEFF followed by content | One U+FEFF removed; rest unchanged | First code unit equals 0xFEFF, so the tool returns slice(1) |
| Any other character | Identical copy of input | First code unit is not U+FEFF, so the tool returns the exact input |
| Two U+FEFF characters | First removed; second sits at position 0 | Unicode treats the second as initial content after a BOM |
| U+FEFF inside visible content | Preserved at its original index | The rule never scans past position 0 |
| U+FEFF after a line break (CRLF or LF) | Preserved at its line | Line endings are not normalized or scanned |
| U+FEFF at the trailing edge | Preserved at the end | No end-of-string trim or remove operation exists |
| Empty input | Empty output | Empty input is a documented no-change case |
| Exactly one U+FEFF and nothing else | Empty string | The result panel renders even with zero visible characters |
Input and Output Boundaries
BOM Remover enforces the same numeric ceiling on both ends: a maximum of 200,000 UTF-16 code units, checked independently for the input you paste and the string the tool returns. The boundary is inclusive — an input that is exactly 200,000 code units is accepted, and the next code unit is rejected before processing begins. A successful operation can never expand the string, since at most one code unit is removed; a separate output-length check after the transformation keeps that invariant testable.
When the leading character is U+FEFF, output length equals input length minus one: output_length = input_length − 1. Substituting input_length = 200,000 gives output_length = 199,999 code units — still well within the document-level ceiling.
There is no silent truncation, no sampling, no substring(0, 200000) shortcut, and no maxLength attribute quietly clipping the textarea. If your string fails the boundary check, the result panel clears along with any earlier successful output so that a stale result cannot be mistaken for a current one. Combined, these rules give you three guarantees: an accepted input reaches the logic, an accepted output reflects the transformation, and a rejected input never produces a partial output at all.
Browser-Only Processing and Clipboard Handling
Nothing leaves the tab. Paste happens into the page's own state, the transformation runs against input.slice(1), and the result sits in a read-only panel that you control. There is no upload of the pasted text to a backend, and the string is not sent to an external service.
Clipboard access is asynchronous, so the copy button pairs the request with a generation identifier. Editing the input, clearing it, retrying, or navigating away invalidates that generation, which means a delayed clipboard permission response cannot paste stale "Copied" state onto a screen that has moved on. If the browser denies clipboard permission, the output panel stays visible and remains fully selectable, so you always have a fallback path to manual copy.
For very large strings, prefer a single paste-and-copy cycle per source so the asynchronous generation matches the visible state you actually want on screen.
When a Decoder Is the Right First Step
BOM Remover is intentionally narrow. It cannot inspect the raw bytes of a file, so it cannot tell you whether your text began life as UTF-8 (EF BB BF), UTF-16 (FE FF or FF FE), or UTF-32 (FF FE 00 00 or 00 00 FE FF). According to the WHATWG Encoding Living Standard, the browser's own decoder is the layer responsible for BOM policy; if you control the file load, configure the decoder to strip or preserve the BOM as your application requires before the string reaches any text field.
Use BOM Remover when:
- A trusted decoder has already produced a string whose leading U+FEFF is interfering with a parser, comparison, shebang, column name, or shell pipeline.
- You want a quick, no-upload confirmation that exactly one invisible character was removed before pasting the result back into source control or a destination system.
- You need to repeat the operation deliberately — for example, on a string that began with two leading U+FEFF characters where you want the first signature gone but the second content character preserved.
Do not use BOM Remover to:
- Infer a file's original encoding from a pasted fragment.
- Convert raw UTF-16 bytes into anything — the tool never sees bytes.
- Repair mojibake, normalize whitespace, or strip every BOM-like character from concatenated documents.
- Rewrite text whose first character is supposed to be U+FEFF on purpose — the tool will remove it.
If the leading U+FEFF is intentional in your content layer, leave it in place. If it is unintended, paste the string into BOM Remover, read the status, and copy the cleaned version locally before pasting it back over the original.