What the checker looks at
Every text file is just bytes, and the encoding is the rule for turning those bytes back into letters. Guess the rule wrong and café becomes café or caf?. This tool reads your file's bytes and works out which rule applies:
| Result | What it means | Typical action |
|---|---|---|
| UTF-8 (no BOM) | Modern, portable, stores every character | Usually nothing — the safe default |
| UTF-8 with BOM | UTF-8 plus a 3-byte marker (EF BB BF) | Great for Excel; strip the BOM if an importer rejects it |
| ANSI / Windows-1252 | One byte per char, Western-European only | Re-save as UTF-8 so accents survive |
| UTF-16 LE/BE | Two bytes per char; unusual for CSV | Convert to UTF-8 for compatibility |
| Mojibake detected | Valid bytes, but the text was mis-decoded earlier | Reverse it with the broken-characters tool |
How to read the result honestly
Two honest limits are worth knowing. First, a pure-ASCII file (plain English, no accents) is byte-for-byte identical whether you call it ANSI or UTF-8, so no tool can tell them apart — and it doesn't matter, because nothing can break. Second, ANSI is detected by elimination: if a file isn't valid UTF-8 and has no BOM, it's almost certainly a legacy Windows-1252 file, but the exact legacy code page can only be inferred, not proven. The checker says so rather than pretending to certainty.
The mojibake flag is different: it means the bytes are valid UTF-8, but they decode to tell-tale sequences like é or “ — a sign the text was decoded with the wrong encoding at some earlier step. That's usually reversible.
If the text is full of é, reverse it with the broken-characters tool. If it's ANSI, re-save it as UTF-8 so accents survive the next system.
Related guides
For the how-to behind the results: save an Excel file as CSV UTF-8, change a CSV's encoding to UTF-8 in a text editor, what a byte order mark actually is, how ANSI and UTF-8 differ and why it decides whether accents survive, and why a file shows ??? or boxes. If the whole file opens as Chinese characters or squares, nothing is corrupted — it is UTF-16 being read as 8-bit text. E-commerce importers are especially strict about this: WooCommerce's product importer expects UTF-8 and rejects garbled descriptions outright, covered in our WooCommerce CSV import guide. Browse all guides.
Frequently asked questions
How do I check what encoding a CSV file is?
Drop the file into the checker above — it reads the first bytes on your device and reports UTF-8, UTF-8 with BOM, UTF-16, or ANSI/Windows-1252, and warns if the text looks like mojibake. Nothing is uploaded. In a text editor you can also read the encoding from the status bar in Notepad++ or VS Code.
What is a BOM and should my CSV have one?
A BOM (byte order mark) is a few invisible bytes at the start of a file announcing its encoding — for UTF-8, the bytes EF BB BF. Excel likes a UTF-8 BOM because accents then show correctly on a double-click, but many importers and database loaders reject a BOM. Add one for Excel, strip it for systems that complain.
What does ANSI vs UTF-8 mean for a CSV?
ANSI on Windows means the Windows-1252 code page: one byte per character, covering only Western-European characters, so anything outside it (many accents, €, emoji) can't be stored and breaks. UTF-8 stores every character, so a file with accents or symbols should be UTF-8. A pure-ASCII file is identical either way.
Is my file uploaded when I check it?
No. The checker reads the file's bytes with the browser's own FileReader and inspects them locally in JavaScript. The file never leaves your device, and the tool works offline once the page has loaded.