Character Encoding Detector
Detect the character encoding of pasted text or an uploaded file — BOM sniffing (UTF-8/UTF-16/UTF-32), a real UTF-8 continuation-byte validator, ASCII detection, and a byte-frequency heuristic for single-byte legacy charsets like Windows-1252 and ISO-8859-1 (Latin-1) when there's no BOM and the bytes aren't valid UTF-8.
Input
Any file type. Read locally in your browser. Used only when the text box is empty.
Output
| Property | Value |
|---|---|
| No data yet | |
All candidates considered
| Encoding | Confidence | Signals |
|---|---|---|
| No data yet | ||
Guides
Garbled text — question marks where accented letters should be, or strings like é in place of é — almost always means a file was written in one character encoding and read back in another. The Character Encoding Detector inspects the raw bytes of pasted text or an uploaded file and reports its most likely encoding, with the byte-level evidence behind that guess.
How to use it
Paste text into Input Text, or drop a file into the uploader to inspect its original bytes. The result updates automatically and shows the Detected Encoding, a Confidence percentage, any BOM found, the byte count, and a plain-English Reasoning line. An All candidates considered table below it lists every encoding the detector weighed, each with its own confidence and reasoning, so you can see the runner-up guesses and why they scored lower.
How detection works
Detection runs through a fixed sequence of checks, from most to least certain:
- Byte order mark (BOM). Some encodings prepend a fixed byte sequence to a file —
EF BB BFfor UTF-8,FF FE/FE FFfor UTF-16, and 4-byte variants for UTF-32. Finding one is close to definitive: 99% confidence. - Pure ASCII. If every byte is in the
0x00–0x7Frange, it's valid ASCII — and, since ASCII is a strict subset of UTF-8, simultaneously valid UTF-8. Reported at 100% confidence. - Valid UTF-8. Without a BOM, a real UTF-8 validator walks the byte stream: it checks that continuation bytes have the right high bits set, rejects "overlong" encodings (more bytes than the codepoint needs), and rejects out-of-range codepoints or lone UTF-16 surrogate halves. That's a genuine grammar check, not just "did decoding throw" — so it catches malformed sequences a lenient decoder would silently accept. Text that passes cleanly is reported as UTF-8 at 97% confidence.
- Single-byte legacy charset guess. If the bytes fail UTF-8 validation, the detector falls back to a byte-frequency heuristic between Windows-1252 and ISO-8859-1 (Latin-1), the two most common single-byte Western encodings. Bytes in the
0x80–0x9Frange are undefined control codes in Latin-1 but printable punctuation (curly quotes, dashes) in Windows-1252, so their presence points toward Windows-1252. This branch is capped well under 70% confidence, because it's a statistical guess, not a certainty — the same bytes are often valid in more than one charset.
Is my data uploaded anywhere?
No. Detection runs entirely in your browser (or, via the API, in the request handler) — nothing is sent to a third-party service.
Why isn't my file detected as Shift_JIS, Big5, or another CJK encoding?
Those legacy multi-byte Asian encodings aren't covered — guessing them from byte ranges alone produces a lot of false positives, unlike the BOM check or a UTF-8 grammar check. If you know a file is Shift_JIS or GBK, decode it directly with that label instead of relying on detection.