Free local encoding diagnostic

Mojibake & Encoding Repair Lab

Compare plausible decodings and reversible repair paths before changing anything. Inspect the original bytes, BOM, line endings and CSV shape, then deliberately copy or download one reviewed result.

1. Add the broken text or original file

Pasted text has already been decoded by another application, so its original bytes are unavailable. Limit: 500,000 UTF-16 units.

Choose or drop a text/data file

File analysis preserves exact bytes and is more reliable. Limit: 5 MiB. Nothing is uploaded.

No file selected.

Paste text, choose a file, or load the example.

All decoding, inspection and export happen in this browser. Files and text are not uploaded or saved.

What mojibake is

Mojibake appears when bytes written in one character encoding are decoded as another. A common example is UTF-8 bytes interpreted as Windows-1252, turning é into é and smart quotes into sequences beginning with â. If the damaged visible text is saved and misdecoded again, the corruption can become double encoded.

This tool keeps the unchanged input as a candidate and shows each attempted transformation. File mode compares direct decodings of the exact bytes. Paste mode can only test reversible repairs on Unicode text because paste events do not expose the bytes that existed before another program decoded them.

How to repair encoding safely

  1. Use the original file when possible so BOM and byte validity remain available.
  2. Compare the likely candidate with other decodings. A readable preview is evidence, not certainty—names, short strings and multilingual text are often ambiguous.
  3. Check replacement characters, NULs, control codes, line endings and any CSV row inconsistencies.
  4. Export only the reviewed candidate. Downloads are encoded as UTF-8, optionally with a BOM; newline conversion is separate and explicit.

Supported encodings and limits

The comparison includes UTF-8, UTF-16LE/BE, Windows-1252, byte-isomorphic ISO-8859-1, Windows-1251, Shift_JIS, GB18030, Big5 and EUC-KR where the browser implements the standard decoder. On the web, labels such as “Latin-1” are often mapped to Windows-1252, so this lab provides a separate byte-isomorphic Latin-1 view rather than hiding that distinction. New files should generally use UTF-8.

Detection is heuristic: this is not language identification and cannot reconstruct bytes that were replaced with U+FFFD or otherwise lost. UTF-32, binary formats, archives, PDFs and office documents are outside scope. Pasted text is limited to 500,000 UTF-16 units and files to 5 MiB to keep the static browser page responsive.

BOM, line endings and CSV

A byte order mark can strongly identify UTF-8 or UTF-16, although a BOM is optional in UTF-8. CRLF, LF and CR are counted separately; mixed newlines are reported rather than normalized automatically. The CSV view tests comma, tab, semicolon and pipe delimiters, respects doubled quotes and line breaks inside quoted fields, and reports non-modal column counts.

The decoder behavior follows the WHATWG Encoding Standard. CSV terminology follows RFC 4180, while acknowledging that real-world dialects vary.

Frequently asked questions

Can the tool always detect an encoding?

No. ASCII-only bytes decode identically under many encodings, and short samples can be ambiguous. The ranking is a review aid; it is not a certainty percentage.

Why can’t a replacement character be repaired?

U+FFFD usually means a previous decoder discarded an invalid byte sequence. Once the original bytes are gone, many different inputs could have produced the same replacement character.

Does downloading modify CSV values?

No. The chosen text is encoded as UTF-8, with only the explicitly selected newline conversion and optional BOM. CSV warnings do not trigger automatic field repairs.

Browse text and Unicode tools · All ToolQuill tools