Overview
Introduction
A CSV file that looks fine in one editor can turn into garbled text the moment it's opened somewhere that assumes a different byte encoding. Figuring out which encoding a file actually uses, before importing it, saves a lot of guesswork.
This tool reads a file's raw bytes and reports its best-guess encoding, along with a preview of the decoded text so you can confirm it looks right.
What Is CSV Encoding Detector?
A file encoding detector that checks an uploaded file's raw bytes for a byte order mark (BOM), then falls back to a strict UTF-8 decode attempt to guess whether the file is UTF-8, UTF-16, or a legacy single-byte encoding like Windows-1252/Latin-1.
It runs entirely client-side as part of this site's String Tools collection; the file's bytes are read and inspected in your browser and are never uploaded to a server.
How CSV Encoding Detector Works
The tool first checks the file's first two or three bytes against the known UTF-8 BOM (EF BB BF), UTF-16 LE BOM (FF FE), and UTF-16 BE BOM (FE FF) signatures. If one matches, the rest of the file is decoded accordingly and reported.
If no BOM is present, the tool attempts a strict UTF-8 decode using the browser's TextDecoder with fatal error mode enabled. If that decode succeeds, the file is reported as UTF-8 with no BOM. If it throws, meaning the byte sequence isn't valid UTF-8, the tool reports that the file is likely Windows-1252 or Latin-1 and decodes it that way for the preview.
When To Use CSV Encoding Detector
Use it before importing an unfamiliar CSV or text file into a tool that requires a specific encoding, or when a file displays garbled accented characters and you need to know why.
It's a fast way to get the answer without opening a hex editor or writing a one-off script just to check a file's bytes.
Often used alongside BOM Detector and Remover and Unicode and Encoding Repair Tool.
Features
Advantages
- Inspects actual raw bytes rather than guessing from already-decoded text, which is the only reliable way to detect a BOM or distinguish valid from invalid UTF-8.
- Checks all three common BOM signatures (UTF-8, UTF-16 LE, UTF-16 BE) before falling back to a decode-attempt heuristic.
- Shows a decoded text preview immediately, so you can visually confirm the guess looks right.
Limitations
- The Windows-1252/Latin-1 fallback is a best guess triggered whenever strict UTF-8 decoding fails; it cannot distinguish Windows-1252 from Latin-1 or from other legacy single-byte encodings (such as Windows-1250 or ISO-8859-15), since many of those encodings assign different characters to the same byte values.
- A file can coincidentally contain byte sequences that are technically valid UTF-8 even though it was actually written in a different encoding, in which case this tool will report UTF-8 incorrectly; always sanity-check the decoded preview.
Examples
Best Practices & Notes
Best Practices
- Always check the decoded text preview, not just the reported encoding label, since the Windows-1252 fallback is a heuristic rather than a certainty.
- If a file is reported as likely Windows-1252/Latin-1 but the preview still looks wrong, try a different legacy encoding in a spreadsheet or text editor that lets you pick one explicitly.
- Re-save files as UTF-8 without a BOM where possible, since it's the most broadly compatible encoding across modern tools.
Developer Notes
Detection order is: 3-byte UTF-8 BOM (EF BB BF) → 2-byte UTF-16 LE BOM (FF FE) → 2-byte UTF-16 BE BOM (FE FF) → `new TextDecoder("utf-8", { fatal: true }).decode(bytes)`, catching the thrown error to fall back to `new TextDecoder("windows-1252").decode(bytes)`. The BOM bytes themselves are stripped from the decoded preview.
CSV Encoding Detector Use Cases
- Diagnosing why a CSV file shows garbled accented characters after opening it in a particular tool
- Checking whether a file exported from Excel has a UTF-8 BOM that might trip up a strict downstream parser
- Verifying a file's encoding before writing an import script that assumes a specific one
Common Mistakes
- Assuming every text file is UTF-8 by default; many legacy exports, especially from older Windows tools, are still Windows-1252.
- Ignoring a UTF-8 BOM and feeding the raw file (BOM included) into a strict parser, which can cause the first field name in a CSV header to be misread.
Tips
- If your downstream tool chokes on a BOM, use the BOM Detector and Remover on the decoded text preview to strip it.
- When in doubt after seeing the Windows-1252 fallback, try opening the file in a spreadsheet application with an explicit "import with encoding" option to compare.