Character Encoding Detector
Load a file and the tool ranks the possible encodings using the BOM, byte-structure validity and how natural the decoded text looks. Each candidate comes with a preview so you can confirm by eye.
How detection works
A BOM settles it immediately. Otherwise each candidate is checked structurally — UTF-8 multi-byte sequence shape and overlong forms, Shift_JIS lead/trail byte ranges, EUC-JP 0x8E/0x8F and 0xA1–0xFE pairs — and the decoded string is scored, penalising control characters, private-use codepoints and U+FFFD while rewarding kana, kanji and ASCII.
Why detection is never certain
Short or ASCII-only text is byte-identical in several encodings, so it cannot be distinguished at all. EUC-JP bytes are also valid as a run of Shift_JIS half-width kana. That is why candidates are ranked rather than asserted.
After detection
Once a preview reads correctly, use the encoding converter to rewrite the file as UTF-8. For spreadsheets, the CSV mojibake tool goes straight to an Excel-ready output.
Frequently asked questions
Which encodings can be detected?
UTF-8 (with or without BOM), Shift_JIS (CP932), EUC-JP, UTF-16LE, UTF-16BE, ISO-2022-JP and plain ASCII.
What does the confidence number mean?
A 0–1 score combining byte-structure validity with how plausible the decoded text is. A BOM gives 1.00. Above 0.9 is effectively certain; around 0.5 you should compare previews.
What happens with a binary file?
Every candidate either fails validation or scores low. If the preview is a wall of symbols, the file is not text.
Is the file uploaded?
No. It is read locally through the File API and analysed in JavaScript.