To strip one leading U+FEFF character from decoded text in your browser, paste the content into BOM Remover, run it once, and copy the result locally; position zero is the only rule the tool enforces, so a second-leading or internal BOM survives the transformation. War Thunder players, mission builders, and modders sometimes run into a stubborn invisible character at the start of a log file, mission script, user mission JSON, replay export, or modded localization file that breaks parsers, regex matches, shebangs, or column-name comparisons. The fix is rarely obvious because U+FEFF has no glyph, so it does not look like a typo; it simply makes the first byte behave like an off-limits character that no one can see in a normal editor view. A reliable local workaround is to copy the file's text into a tool that checks exactly one position, run the transformation, and paste the cleaned result back into the original document. This guide explains what that tool actually does, the exact boundaries of what it preserves, and the steps to remove a leading BOM from a War Thunder file in your browser without uploading anything to a remote server.
What BOM Remover actually does for War Thunder files
BOM Remover is a deliberately narrow text utility that exists for one job: deciding whether the first UTF-16 code unit of a pasted JavaScript string is U+FEFF. If it is, the tool removes exactly that one code unit. If it is anything else, the tool returns the input unchanged. There is no trim, no global replace, no whitespace normalization, no encoding detection, and no upload step, which makes the behavior easy to reason about when you are troubleshooting a file that came out of War Thunder's tools or a community modding pipeline.
The tool works on already decoded text because a browser textarea holds decoded characters, not raw bytes. That means the tool cannot tell you whether the original file was UTF-8 with the EF BB BF signature, UTF-16 with FE FF or FF FE, or UTF-32 with FF FE 00 00. All it sees is the resulting string after the browser has done its decoding work. Position is the entire rule, so the same transformation behaves the same way regardless of how the original bytes were written, which keeps the tool predictable when you are bouncing files between Windows, Linux, and macOS editors.
How to remove a leading BOM from a War Thunder file
- Open the War Thunder file in a text editor that lets you copy its complete contents, including any invisible characters at the very top. Notepad++, VS Code, or your editor's "show invisible characters" mode will display the leading BOM as a tiny U+FEFF marker or a question mark, which is the cue that the file actually starts with a BOM and not with the character you expected.
- Select the entire file content from the first character to the last, then copy it to the clipboard. Do not run find-and-replace or a global BOM scrubber yet; the goal is to feed the tool the original decoded string so you can audit exactly what changed.
- Paste the copied text into the BOM Remover input area in your browser. The tool accepts up to 200,000 UTF-16 code units, so files such as long replay exports, large localization tables, or verbose community log dumps are well within range.
- Run the remover and read the status line. The summary tells you either that exactly one leading U+FEFF was removed, or that no leading U+FEFF was found, and it reports the resulting output length in UTF-16 code units so you can confirm a length change of zero or one.
- Review the complete output, including every CRLF or LF line ending, trailing whitespace, internal tabs, and any U+FEFF that was originally positioned after the first character. None of those are normalized or filtered, which is exactly what you want when a parser is sensitive to line endings or column counts.
- Copy the cleaned output and paste it back into your editor over the original file content. Save the file in the encoding your downstream War Thunder workflow expects, typically UTF-8 without BOM for user mission scripts and modded localization files, then reload the file through your normal pipeline to confirm the parser, regex, or column comparison now passes.
War Thunder file types that commonly carry a leading BOM
War Thunder's official game files are usually shipped without a BOM, but the moment you start copying content between tools, exporting logs, or hand-editing mod files, a leading U+FEFF can sneak in. User mission scripts saved by certain Windows editors inherit that editor's default BOM policy. Replay exports that route through a Windows console or a PowerShell pipeline occasionally start with a BOM because the host shell added one during redirection. Localization tables shared between community translators frequently carry a BOM that comes from the original contributor's editor and then propagates through every contributor who opens and resaves the file.
Mission JSON for the user mission editor behaves the same as any other JSON, so a single leading U+FEFF can break a parser that expects the first character to be { and instead receives a zero-width character. Database dumps, log exports, and CSV-style configuration tables that come out of Excel-based community tools often have a BOM at position zero, which is why so many first-character comparisons silently fail even when the visible text looks identical. If you are seeing parser errors, regex misses, or column-name mismatches that begin at the first character of a War Thunder-related file, the leading BOM is the first thing to verify before changing any other part of the workflow.
What the tool preserves and what it changes
The transformation is intentionally minimal so that you can predict its effect on a real War Thunder file. The table below summarizes what BOM Remover does in each documented scenario, drawn directly from the tool's verified behavior.
| Scenario | Tool behavior |
|---|---|
| First character is U+FEFF | Removes exactly that one code unit |
| First character is anything else | Output is identical to input |
| U+FEFF after the first character | Preserved, even if it sits mid-string or right after a line break |
| Two consecutive U+FEFF at the start | First removed, second remains at the start of the output |
| Empty input | Valid no-change case, output is empty |
| Input contains only one U+FEFF | Output is empty and the result panel still renders |
| CRLF, LF, tabs, NUL bytes, emoji, combining marks, non-Latin scripts | Preserved verbatim, no normalization or filtering |
| Input over 200,000 UTF-16 code units | Rejected before processing, no partial result shown |
| Output over 200,000 UTF-16 code units | Rejected with an explicit invariant test failure |
Because the transformation only ever removes zero or one code unit, a valid production input cannot expand during processing. That is a useful invariant when you are checking whether the tool actually did anything to your file: the output length will be the input length, or the input length minus one, and never anything in between. An internal U+FEFF, a trailing U+FEFF, a U+FEFF sitting after a CRLF line break, and any second-leading U+FEFF are all kept in place, which is the documented Unicode treatment for non-initial byte order marks.
Limits and safety rules
BOM Remover accepts up to 200,000 UTF-16 code units of input and applies the same hard ceiling to the output. An input sitting exactly at 200,000 code units is accepted; the next code unit is rejected before processing. Output validation accepts the exact boundary and rejects boundary plus one, which means a successful result is the only kind of result you can copy. Nothing is shortened, sampled, or partially returned, and the tool never silently fails because of an HTML attribute cap.
Editing or clearing the input immediately clears the previous output, error, summary, removal flag, copy message, and any pending copy timer. An over-limit error cannot leave an older successful result visible, which protects you from copying stale data after a retry. Clipboard access is asynchronous, so every copy is guarded by a generation identifier; a late permission response cannot restore a stale "Copied" badge, and a denied clipboard request still leaves the full read-only output available for manual selection.
When to skip BOM Remover and choose a different approach
BOM Remover is the wrong tool when you actually need to identify a file's original byte encoding, convert UTF-16 bytes to UTF-8, validate that a file is well-formed UTF-8, repair mojibake, strip every zero-width character, or sanitize a concatenated document of every BOM-like byte. The tool works on already decoded text and cannot tell whether a file once contained the EF BB BF, FE FF, or FF FE byte signatures documented by the WHATWG encoding standard. If you control how the file is loaded, choose a decoder with an appropriate BOM policy, such as a strict "no BOM" reader for mission JSON or a "strip on read" option for CSV imports. If you must paste text into BOM Remover, verify that the leading U+FEFF is genuinely unwanted before you copy the result back over the original file, because a BOM at position zero is sometimes intentional content.
For War Thunder workflows in particular, the tool is best used after a trusted decoder or editor exposes a leading U+FEFF that interferes with a parser, comparison, shebang, or column-name check. Once the file is clean, save it in the encoding your downstream tool expects and reload it through your normal pipeline. That keeps the transformation auditable: one click, one position, one removal, and a result you can copy locally without sending the file anywhere.
For a deeper look, see How to Remove a Bommer Character From Pasted Text.