Unicode Character Inspector
Inspect each Unicode character, encoding, category, script and normalization form.
Detect and repair text that was decoded with the wrong character encoding, then compare the most plausible results.
Repair processing occurs on the UnicodeNow server only after you press Find repair candidates. Submitted text is used only to generate repair candidates and is not stored in the database, Redis, analytics, URLs or application logs.
Select a candidate to populate this output. The original input is never overwritten.
Paste garbled text to look for mojibake repair candidates.
| Original sequence | Repaired sequence | Original code points | Repaired code points | Recovered bytes | Explanation | Pass |
|---|
No candidate selected.
Mojibake occurs when bytes written using one character encoding are decoded using another. For example, café stored as UTF-8 can appear as café when the UTF-8 bytes are interpreted through Windows-1252 or ISO-8859-1.
The tool detects common mojibake patterns, tries a bounded set of justified repair paths, scores and deduplicates candidates, explains each transformation, and lets you choose the result. Repair is heuristic and cannot be guaranteed.
Encoding repair can be ambiguous. Windows-1252 and ISO-8859-1 can produce the same result for some text, while punctuation and emoji often require Windows-1252. Showing candidates helps avoid silently choosing the wrong repair.
Common paths include Windows-1252 → UTF-8, ISO-8859-1 → UTF-8, bounded double-encoded UTF-8 repair and selected legacy encodings from an allowlist. Arbitrary codec names are not accepted.
café
→ café
→ café
Double encoding needs more than one bounded pass. The tool stops early when output stops improving, repeats, or reaches the configured pass limit.
� is U+FFFD REPLACEMENT CHARACTER. It usually means a decoder already lost byte information, so exact restoration may not be possible.
Yes. Already-correct text such as café and it’s ready should not be repaired blindly. When no strong mojibake indicators are present, this tool warns and avoids automatic selection.
NFC, NFD, NFKC and NFKD do not repair wrongly decoded bytes. Optional NFC normalization here is separate from encoding repair and is reported separately.
Processing is server-side and bounded. The service reconstructs bytes from visible mojibake using an explicit encoding allowlist, decodes those bytes as UTF-8, scores candidates with documented heuristics, deduplicates identical outputs, caps candidate count and never invokes arbitrary codecs or shell commands.
Repair processing occurs on the UnicodeNow server. Submitted text is used only to generate repair candidates and is not stored in the database, Redis, analytics, URLs or application logs. Responses are returned with Cache-Control: no-store.
Mojibake is garbled text caused when bytes written in one encoding are decoded using a different encoding.
The UTF-8 bytes for café were likely interpreted as Windows-1252 or ISO-8859-1 text, producing café.
The visible mojibake is encoded back as Windows-1252 bytes, then those bytes are decoded as UTF-8.
It is text that went through a wrong decode more than once, such as café becoming café and then café after two passes.
It can try bounded one-pass and two-pass repairs and records the pass history when a candidate improves.
Yes. If no clear mojibake indicators are present, the tool warns and does not automatically select a repair.
Encoding repair can be ambiguous. The tool shows plausible bounded paths instead of assuming the first result is correct.
Confidence is a heuristic based on removed mojibake markers, remaining replacement characters, control characters, pass count and whether the result improves.
U+FFFD usually means a decoder already lost some byte information, so exact recovery may not be possible.
No. Repair requires enough reversible information to reconstruct the original bytes.
No. Normalization compares equivalent code-point sequences; mojibake is an encoding mismatch.
The bounded allowlist supports Windows-1252, ISO-8859-1 and Windows-1251 repair paths, plus bounded double-encoded UTF-8 repair.
Repair candidate generation runs on the UnicodeNow server after you press the button. It is not submitted while typing.
No. Submitted text is processed in memory only and is not stored in the database, Redis, analytics, URLs or application logs.
Inspect each Unicode character, encoding, category, script and normalization form.
Convert text to UTF-8 bytes and validate byte sequences.
Validate hexadecimal byte sequences as UTF-8.
Compare likely text encodings from raw bytes or byte-like input.
Normalize, trim and clean problematic Unicode text safely.
Convert UTF-8 text bytes into hexadecimal values.
Decode hexadecimal byte values into UTF-8 text.
Unicode defines characters and code points. UTF-8 encodes those code points as bytes for files, databases, web pages, APIs and network messages.
Learn why text becomes garbled, how UTF-8 bytes turn into mojibake such as café and It’s, and how to repair it safely.
A safe workflow for diagnosing broken UTF-8, validating bytes, reversing mojibake, handling double encoding and auditing repairs.