Does the BOM Remover delete every U+FEFF in my text?

No. It removes exactly one leading U+FEFF, the one at position zero of the string. Every internal, trailing, or second leading occurrence is preserved.

Can I paste raw bytes that include EF BB BF?

The tool operates on decoded text. You should decode the file first so the three bytes appear as a single U+FEFF character, then paste that string.

What does the status line tell me?

It reports whether exactly one leading U+FEFF was stripped or whether the input did not begin with one, so you know the operation actually did something.

Will line endings be changed?

No. The remover targets only the first character, so CRLF and LF endings elsewhere in the text stay exactly as they were.

Is the tool safe for sensitive content?

Yes. The processing happens locally in your browser on whatever you paste, so the text is not uploaded to a server.

What if my text starts with two U+FEFF characters?

Only the first one is removed. The second remains in place, which is the correct behavior when a zero-width no-break space is intentional content.

How to Remove a Leading BOM From Text in Your Browser

A leading BOM is a single invisible U+FEFF character placed at the very start of decoded text, and removing it means stripping exactly one of those characters from position zero of your string while leaving every other occurrence alone. The BOM Remover does precisely that: paste your decoded text, run it through the tool, and it deletes one leading U+FEFF if present, then reports whether anything was removed. Open the tool directly at /dev/bom-remover/ whenever you need a quick, local cleanup before saving a file, pasting into a parser, or feeding text to another tool.

Many developers first meet U+FEFF the hard way: a script throws "unexpected token", a CSV import shifts the first column by one cell, or a JSON parser refuses to read a file because the very first character is not the brace it expected. In UTF-8, that single invisible character is the byte order mark EF BB BF, and even though it is valid Unicode, it is rarely valid as the first character of application data. The cleanest fix is to remove exactly one of them from the start of the string and then verify that no further invisible content is hiding elsewhere in your text.

What a Leading BOM Actually Is

U+FEFF is the "ZERO WIDTH NO-BREAK SPACE" character that the Unicode standard also defines as a byte order mark at the start of a stream. When a file is saved as UTF-8 with BOM, the editor writes the three bytes EF BB BF before the first visible character, and a decoder reproduces those bytes as a single U+FEFF codepoint at index zero of the resulting JavaScript or Python string. That single character has no width, no glyph, and no sound, but it still counts as a character for parsers, regexes, and length checks. According to the Unicode FAQ on BOMs, the mark is optional in UTF-8 and is recommended only for files whose encoding cannot otherwise be inferred, which is why downstream consumers such as JSON parsers, CSV importers, and shell pipelines frequently choke on it.

The tricky part is that the mark is invisible. A human reader sees "hello", a parser sees "\uFEFFhello", and the difference is the difference between success and a cryptic syntax error. The right tool removes only the leading occurrence so that any intentional U+FEFF later in the text — say, a zero-width joiner inside a multilingual string — stays exactly where it was.

When You Need to Strip a Leading BOM

The most common situations where you reach for a BOM remover involve a pipeline that consumes decoded text. If you copied JSON out of an editor that saved with a BOM and then dropped it into a validator, the validator will trip on the first character before it ever reads the opening brace. The same thing happens when you paste a CSV row into a spreadsheet, feed a string into a regex tester, or hand a payload to a token decoder. The JSON Validator, for example, will report a parse error on column 1 if the very first character is U+FEFF rather than "{" or "[".

Another common case is exporting a report or a log line from a Windows tool that defaults to UTF-8 with BOM. The file looks fine in a browser, but a Unix script using awk, cut, or a shell loop will treat the leading mark as part of the first field. Removing it on the receiving side, after decoding, keeps the source file intact while making the data safe for downstream tools that assume a clean first character.

Remove a Leading BOM Step by Step

Make sure your text is already decoded into characters; the BOM Remover operates on the string layer, not on raw bytes.
Open the BOM Remover in your browser so the paste area and status line are both visible.
Paste the full text into the input area, including the invisible leading U+FEFF if one is present, and leave every internal or trailing occurrence untouched.
Run the remover and watch the status line; it tells you whether exactly one leading U+FEFF was stripped or whether the input did not start with one.
Review the complete output, checking line endings and any intentional later U+FEFF content that should be preserved, before copying it locally.
Copy the cleaned text from the output area into the next tool in your pipeline, such as the JSON Formatter or the Diff Checker for verification.

Behavior to Expect From the Tool

The remover is deliberately narrow: it touches only the very first character and only when that character is exactly U+FEFF. If your text starts with a normal character, the status will say no leading BOM was found and the output will match the input byte-for-byte. If your text starts with two consecutive U+FEFF characters, only the first one is removed and the second stays in place, which is useful when you genuinely have content that begins with a zero-width no-break space after the encoding marker.

Input starts with	Output starts with	Status meaning
One U+FEFF, then visible text	Visible text only	Exactly one leading BOM removed
Two U+FEFF, then visible text	One U+FEFF, then visible text	One leading BOM removed, second preserved
No U+FEFF at position 0	Unchanged input	No leading BOM was present
Visible text with U+FEFF inside	Unchanged input	Internal occurrences preserved by design

This narrow behavior matters when you also rely on zero-width characters for legitimate purposes, such as separating emoji sequences or marking bidirectional text. A naive stripper that removes every U+FEFF would corrupt those sequences, while the BOM Remover leaves them intact and only acts on the first character.

Verifying the Result Before You Continue

After running the remover, glance at the output for any sign that a stray invisible character is still hanging around. A quick sanity check is to paste the result into the ASCII Table reference for any character whose decimal value is 65279, the numeric form of U+FEFF, or to drop the result into the Regex Tester with the pattern /^\uFEFF/ to confirm there is no match at the start. You can also compare the original and the cleaned text with the Diff Checker to see exactly which single character at the head of the file was affected, which gives you confidence that nothing further down the line was changed.

When the status line reports a successful removal, copy the output and proceed with your original task. If the status reports that no leading BOM was found, the issue you are debugging is somewhere else entirely — most likely a stray whitespace, a smart quote, or an encoding mismatch on a different layer — and the remover was the right tool to rule out the simplest explanation.

Common Pitfalls When Removing a BOM

Pasting raw bytes that include the EF BB BF sequence, rather than the decoded U+FEFF character, will leave the remover unable to detect a leading mark because the input area expects a text string, not a byte stream. Decode first, then paste. Another pitfall is re-saving the cleaned text through an editor that adds the BOM back on export, which silently undoes your cleanup. When you can, switch the editor's default to UTF-8 without BOM, or save the cleaned text through a tool that explicitly omits the encoding signature.

Pitfall	Symptom	Fix
Pasting raw bytes, not decoded text	Status says no BOM found even though the file has one	Decode the file first, then paste the resulting string
Editor re-adds BOM on save	Cleaned text still triggers the same error downstream	Re-export using UTF-8 without BOM
Stripping every U+FEFF instead of one	Breaks zero-width joiners inside emoji or RTL sequences	Use a tool that targets only the leading occurrence
Running on a binary file	Output looks corrupted or shifted	Only feed the remover decoded text, never raw binary

Where This Fits in a Developer Workflow

A practical workflow is to identify, strip, and verify in three steps. First, identify by feeding the suspect string into a validator or diff tool that shows the offending character, as described in the guide on how to check if your JSON format is correct. Second, strip with the BOM Remover so that exactly one leading U+FEFF is removed and nothing else changes. Third, verify by re-running the same validator or by comparing original and cleaned output through the Diff Checker, which will show a single-character difference at the head of the file. This three-step loop catches the leading BOM without disturbing any legitimate zero-width content later in the string.

When you keep the remover open in a tab alongside a JSON formatter, a JSON validator, and a diff checker, you have a small browser-based workstation for cleaning up text exports. Because the BOM Remover runs locally on pasted text, your string never leaves the browser, which matters when the text contains configuration, credentials, or anything else you would rather not transmit.