Inspect a file's leading bytes for UTF-8, UTF-16 LE/BE, or UTF-32 LE/BE Byte Order Marks, remove only the matched signature, and download the remaining bytes without decoding or re-encoding them. Processing stays in this browser, reports byte-order ambiguity and size limits, and keeps decoded-text previews separate from the byte-preserving download so the tool never guesses an encoding or silently rewrites content.
Continue with a related workflow or open the next tool that usually follows this task.
Use this workflow when an invisible leading signature changes the first CSV header or script token. Work from the original bytes, distinguish UTF-32 LE from its UTF-16 LE prefix, and do not remove UTF-16 or UTF-32 byte-order evidence until the destination is known.
OpenRelated toolInspect BOM, strict UTF-8, Unicode structure, ASCII compatibility, and binary clues from local file bytes.
OpenRelated toolConvert CSV and JSON locally with text-safe typing, strict structure checks, and protected spreadsheet output.
OpenRelated toolCount original CRLF, LF, CR, and Unicode line separators in a local file.
OpenChoose File bytes when the original file is available; use Decoded text only for a string that another program has already decoded.
Select one file up to 25 MiB or load the built-in UTF-8 BOM CSV sample.
Run the inspection manually so no bytes are removed merely because a file was selected.
Check the detected encoding label, signature length, and before/after leading-byte evidence.
For UTF-16 or UTF-32, confirm that the destination knows the LE or BE byte order before downloading.
Download the changed file, then retry the target importer or parser and verify the first field, token, and file encoding contract.
Remove EF BB BF when a CSV importer treats the first header as an unexpected hidden-prefixed field while preserving every row byte after it.
Prepare a UTF-8 shell, Node, Python, or config file for a parser that requires an ASCII token such as #! or { at byte zero.
Strip an explicitly unwanted UTF-16 or UTF-32 signature when the receiving interface already specifies UTF-16LE, UTF-16BE, UTF-32LE, or UTF-32BE.
Use the before/after hex prefixes to document exactly which bytes changed before handing a repaired export to an ETL or database import job.
Inspect a copied string for one decoded leading U+FEFF while preserving any later U+FEFF characters for separate Unicode review.
Reading a UTF-16 or UTF-32 file as browser text and saving it as UTF-8 changes every encoded code unit. File mode removes only the leading signature bytes and preserves the remaining byte sequence.
A UTF-16 or UTF-32 BOM can be the only byte-order signal in an unlabelled stream. Remove it only when the destination already requires or knows the exact LE or BE encoding.
A BOM is a signature at byte zero. U+FEFF or BOM-shaped bytes later in the content are preserved because deleting them could change data rather than file metadata.
No BOM does not prove that a file is UTF-8, ASCII, or any other encoding. This tool identifies supported leading signatures; it does not guess an unmarked file's charset.
A prefix such as EF BB without BF may be a damaged UTF-8 signature or ordinary non-text bytes. The tool reports a possible truncated signature and removes nothing.
The three UTF-8 signature bytes are removed from a CSV header while the bytes for id,name remain unchanged.
EF BB BF 69 64 2C 6E 61 6D 6569 64 2C 6E 61 6D 65The four-byte UTF-32 LE signature must be detected before its FF FE prefix can be mistaken for UTF-16 LE. The remaining UTF-32 LE bytes are not decoded.
FF FE 00 00 69 00 00 00 64 00 00 0069 00 00 00 64 00 00 00The supported signatures are EF BB BF for UTF-8, FE FF and FF FE for UTF-16 BE/LE, and 00 00 FE FF and FF FE 00 00 for UTF-32 BE/LE.
Four-byte UTF-32 signatures are tested before two-byte UTF-16 signatures because UTF-32 LE begins with FF FE. This prevents a prefix collision from removing only half of the marker.
File mode operates on Uint8Array data. It copies the byte range after the signature into the result without TextDecoder, TextEncoder, Unicode normalization, newline conversion, or trimming.
Decoded-text mode is a different contract: it checks whether the first UTF-16 code unit is U+FEFF, rejects unmatched surrogates, removes at most that one character, and encodes downloads as UTF-8.
An incomplete prefix is evidence, not permission to mutate. When a short stream matches only the beginning of a supported signature, the result remains byte-for-byte unchanged and displays a warning.
The browser limits file input to 26,214,400 bytes and decoded text to 1,048,576 UTF-8 bytes. Processing stays on the device in the normal workflow, while aggregate analytics excludes names and content.
File mode recognizes five Unicode signatures at byte zero: UTF-8 EF BB BF, UTF-16 BE FE FF, UTF-16 LE FF FE, UTF-32 BE 00 00 FE FF, and UTF-32 LE FF FE 00 00.
No. The file path reads an ArrayBuffer, removes only the detected leading bytes, and places the remaining bytes into the download. It does not decode, normalize, change line endings, or encode the file again.
The text box receives characters after another program has already decoded them. It can remove one leading U+FEFF character, but it cannot recover the source file's original UTF-16 or UTF-32 byte order. Its download is UTF-8.
Only when the receiving parser expects BOM-free UTF-16 or already knows the byte order from a charset label or file contract. Without that information, removing the BOM can make an unlabelled UTF-16 or UTF-32 stream ambiguous.
No. It means none of the five supported signatures was found at byte zero. Charset detection for unmarked files is a separate, heuristic task.
No. U+FEFF away from the beginning may be content or legacy word-joining data. This tool preserves interior occurrences; use a Unicode inspector when you need code-point-level review.
The selected file is read and processed in the browser during the normal workflow. Aggregate events can record mode, byte counts, detected signature type, and success or failure, but not the file name, file bytes, pasted text, or output.
Maintained and tested by SimpleWebUtilsReviewed
Method: For “Repair a UTF-8 BOM CSV before database import”, we entered the documented fixture in Remove BOM from UTF-8, UTF-16, and UTF-32 Files and followed “Inspect file bytes instead of opening and resaving text” before “Resolve incomplete or missing signatures conservatively”. We compared the browser result with the stated output, then reviewed “Using decoded text mode when the original file exists” and “Removing FF FE before checking for UTF-32 LE” as separate failure boundaries.
Expected result: Removing exactly EF BB BF reduced the file from 34 to 31 bytes and made id the first header bytes without decoding and rewriting the remaining CSV.
Sources and standards
Use these focused guides when you need a practical workflow before opening the tool.
Use this workflow when an invisible leading signature changes the first CSV header or script token. Work from the original bytes, distinguish UTF-32 LE from its UTF-16 LE prefix, and do not remove UTF-16 or UTF-32 byte-order evidence until the destination is known.
Workflow guideUse the original file bytes to distinguish confirmed Unicode signatures from structural evidence and conservative heuristics. Then verify a candidate decoder against known headers and multilingual values before a full import.
Workflow guideCharacter-set detection narrows decoder candidates; it does not reverse already-corrupted text by itself. Preserve the source, identify where the wrong decode happened, compare controlled previews, and convert once only after known values round-trip correctly.
Workflow guideUse this incident workflow when a Windows-edited script fails on Linux, Git shows a whole-file line-ending diff, or generated text mixes CRLF and LF. Inspect first, normalize only confirmed text, then enforce the decision with repository settings.
Workflow guideUse this workflow when two values look identical but compare, search, wrap, parse, or render differently. Map supported controls before editing, distinguish common hidden separators from joining and line-break controls, retain exact line endings and normalization, and record why each removal was safe.
Continue with another maintained workflow
Inspect BOM, strict UTF-8, Unicode structure, ASCII compatibility, and binary clues from local file bytes.
Convert CSV and JSON locally with text-safe typing, strict structure checks, and protected spreadsheet output.
Count original CRLF, LF, CR, and Unicode line separators in a local file.
Normalize Unicode with code-point evidence and explicit compatibility-loss warnings.
Detect six zero-width controls, inspect their positions, and remove only approved types.