Does BOM Remover strip every BOM from the file?

No. It removes at most one U+FEFF, and only at position zero. Internal, trailing, and second-leading U+FEFF characters are preserved, and other invisible characters are outside the tool's scope.

Can the tool tell whether the original file was UTF-8, UTF-16, or UTF-32?

No. Pasted text is already decoded, so the tool sees characters, not the original EF BB BF, FE FF, FF FE, or other raw byte signatures.

What happens if my file starts with two BOMs in a row?

Only the first U+FEFF is removed. The second remains at the beginning of the output because Unicode permits it to represent initial content after a BOM. Running the tool again would then remove that newly leading character.

Why does an empty result still count as a successful run?

An input that consists of a single U+FEFF correctly produces an empty output. The result panel and summary distinguish that successful transformation from a missing or failed result.

Will this work on a file saved by Windows Notepad?

Yes, once the file's content is pasted as decoded text. The tool does not inspect the raw EF BB BF bytes; it only checks the first character of the decoded string and removes it if it equals U+FEFF.

How to Remove the UTF-8 BOM From a File in Windows

Windows Notepad and several Windows editors save UTF-8 files with a three-byte byte order mark (EF BB BF) at the very start of the file, and that single signature is what 'UTF-8 with BOM' means on this platform. Once any program reads the file and decodes the bytes into Unicode characters, those three bytes collapse into one invisible character at position zero: U+FEFF. From that moment the BOM is no longer a question of bytes; it is a single invisible code point sitting at the start of a JavaScript string, and that is the level at which the BOM Remover tool works. The transformation happens entirely inside the browser tab, nothing is uploaded, and the status panel tells you whether a leading U+FEFF was actually found and removed before you copy anything back to a file. Internal content, line endings, and any later U+FEFF occurrences are preserved by design, because Unicode treats non-initial U+FEFF characters as content rather than as part of an encoding signature.

how to remove bom from utf-8 file in windows

Why Windows Saves UTF-8 Files With a BOM

Windows Notepad saves plain text files using "UTF-8 with BOM" by default, which prepends the three-byte sequence EF BB BF to the very first byte of the file. That sequence is the UTF-8 byte order mark, and it is what every Windows tool means when it labels a file "UTF-8 with BOM". Once any program reads the file and decodes the bytes into Unicode characters, those three bytes collapse into one invisible character at position zero: U+FEFF. From the perspective of a string in memory, there is no longer any EF BB BF; the BOM has become a single code point sitting at the start of the text.

The BOM is not strictly necessary for UTF-8. UTF-8 has a fixed byte order, so the Unicode Consortium explicitly recommends against using a BOM on UTF-8 encoded text, and the WHATWG encoding standard treats the presence of EF BB BF at the start as one of several possible signatures rather than a requirement. Windows still uses it because older Microsoft tools expected a signature to identify the encoding, and that habit has carried forward into modern Notepad. The signature is invisible in most editors, which is why so many developers discover it only when a script, parser, or shebang line refuses to work.

When That Leading BOM Actually Breaks Something

Most Windows editors hide a leading BOM well enough that you forget it is there. The moment a tool that does not expect it reads the file, the invisible character turns into a real first-character error. The receiving program sees a string that starts with U+FEFF instead of the character the file's author intended, and that single mismatch is enough to derail parsing.

Scenario on Windows	What the leading U+FEFF actually does
Unix-style script or shebang line	The interpreter sees "\uFEFF#!" instead of "#!" and either rejects the file or treats the BOM as part of the command name.
CSV first column header	Header keys end up prefixed with U+FEFF, so a lookup for "name" silently fails and joins stop matching.
Strict JSON parser	Many parsers reject U+FEFF at position zero, producing a parse error that points at line 1 column 1 of an apparently empty file.
Diff or merge tool	Two files that look identical can report every line as changed because only one of them carries the invisible first character.

If your file is causing any of these symptoms and you have already ruled out a real content problem, the leading BOM is a strong candidate for the cause and worth investigating before you rewrite working code.

Remove the BOM From a UTF-8 File in Windows

The tool that does this safely is BOM Remover. It works on the decoded string level rather than on raw bytes, which is the correct layer for a Windows file once a decoder has turned it back into characters. The procedure below works regardless of which Windows editor you used to create the file, because every step past the initial copy operates on the already-decoded text.

Open the file in an editor that lets you copy the raw content (Notepad, Notepad++, VS Code, or any tool that displays the text). Avoid pasting it through a rich-text program that may strip or add invisible characters.
Select the entire content of the file and copy it to the clipboard with the usual Ctrl+A, Ctrl+C shortcut.
Paste the content into the input area of BOM Remover. The tool accepts up to 200,000 UTF-16 code units of input, which is enough for typical source files, configuration files, and small data exports in a single pass.
Run the remover and read the status line. It will state whether one leading U+FEFF was removed or no leading U+FEFF was found, and it will report the new output length in UTF-16 code units so you can confirm the change took effect.
Review the complete output, including line endings and any intentional later U+FEFF content. Internal, trailing, and second-leading U+FEFF characters are preserved by design.
Copy the result locally and save it back to a new file (or overwrite the original) using your editor's "UTF-8 without BOM" or "UTF-8" encoding option so the file is not regenerated with the same signature.

If the status reports that no leading U+FEFF was found, the problem is not a UTF-8 BOM and the tool deliberately leaves your text untouched. For a related walkthrough focused on file-level handling rather than the Windows-specific cause, see this walkthrough of removing a BOM from a file locally in your browser.

What BOM Remover Changes and What It Leaves Alone

The whole tool is built around a single rule: position is everything. It inspects input.charCodeAt(0) against the hexadecimal value FEFF, and if the first character matches it returns input.slice(1); otherwise it returns the exact input string unchanged. There is no trim, no global replace, no scan for other invisible characters, and no rewriting of line endings. That narrow contract is the reason the tool is safe to run on text that may contain legitimate U+FEFF elsewhere.

Position of the U+FEFF in the input	What BOM Remover does
First character (the leading BOM)	Removed; output is the rest of the string and the summary marks a successful removal.
Second character after another BOM	The first BOM is removed; the second becomes the new first character and stays in place.
Middle of the string, after a line break, or at the end	Preserved exactly. Unicode treats these as zero-width no-break space content rather than an encoding signature.
Only character in the input	Removed; the result panel renders an empty output and the summary still marks a successful removal.
No U+FEFF at position zero	Output is identical to the input; the summary reports that no leading BOM was found.

CRLF and LF line endings, tabs, NUL bytes, emoji, combining marks, surrogate pairs, and non-Latin scripts all pass through unchanged. The JavaScript lexical grammar treats U+FEFF outside a leading position as whitespace-bearing content, which is why the tool leaves it in place; for details on how the language itself categorises these characters see the MDN reference on JavaScript lexical grammar.

Stop the BOM Before It Gets In

Cleaning files after the fact is a workaround, not a fix. If you control how a file is saved on Windows, pick a saver that does not prepend EF BB BF in the first place. Notepad on Windows 10 and later exposes a plain "UTF-8" option that does not write a BOM, and most third-party editors such as Notepad++, VS Code, and Sublime Text ship with "UTF-8 without BOM" as either the default or a one-click toggle in the encoding menu. Pick that option once and future saves will arrive without the invisible first character, which saves you from reaching for a remover tool every time.

If you are receiving files from a source you cannot change (a vendor, a colleague's older tool, a legacy export script), BOM Remover remains the right tool for the decode-time problem. It cannot read raw bytes, so it cannot tell you whether the source file originally had the EF BB BF signature, the UTF-16 FE FF signature, or any other byte-level marker; that distinction only exists before a decoder has run. Once a Windows editor has opened the file and exposed the leading U+FEFF to your clipboard, the tool is exactly the right scope: position zero, nothing more. Use it when the leading BOM is interfering with a parser, comparison, shebang, column name, or other first character, and reach for an editor-level fix when you can pick the encoder yourself.