Legacy charset URL decoder
Percent-encoding encodes bytes, and nothing in the URL says which character set those bytes were meant to be. Standard decoders assume UTF-8, so a query string written by a 2004 Japanese or Russian site comes back as mojibake. Paste it here, and every supported charset is decoded side by side with a count of broken characters, so the right one is obvious.
All charsets, ranked by how few characters break
How to use
- Paste the percent-encoded fragment — the whole query string, or just the one parameter value that came back garbled.
- Ignore the Charset selector at first and look at the All charsets table. The Bad chars column counts U+FFFD replacement characters; a zero there means those bytes are valid in that charset.
- Read the decoded column and pick the row that produces real words. Several charsets can score zero — Cyrillic bytes are valid in both KOI8-R and windows-1251, but only one gives readable Russian.
- Copy directly from that row, or set the Charset selector to it and use the main output box.
- The status line names a better-scoring charset if the one you picked is producing broken characters.
Why a zero score is not proof
Single-byte charsets like windows-1251, KOI8-R and Latin-1 define a character for all 256 byte values, so they can never produce a replacement character — every byte sequence "decodes cleanly" in all of them. That is why the table is a shortlist, not an answer: use the score to eliminate the multi-byte charsets that genuinely fail, then use your eyes on the single-byte ones. If the text should be Russian and windows-1251 gives you Russian while KOI8-R gives you consonant soup, you have your answer.
This tool only decodes. Encoding text into a legacy charset is not possible in the browser — TextEncoder emits UTF-8 and nothing else, by design in the WHATWG Encoding standard. If you need to produce legacy-encoded escapes, do it server-side with iconv.
FAQ
How do I know the bytes are not UTF-8 in the first place?
UTF-8 is strict, so invalid sequences show up immediately: the utf-8 row will have a non-zero Bad chars count. If utf-8 scores zero and still looks wrong, the text is probably double-encoded rather than mis-charsetted — try the double URL decoder.
What about + in the input?
Treated as a space, since these strings almost always come from form-encoded query strings. Raw non-escaped characters are read as their UTF-8 bytes before charset decoding.
Which charsets are available?
Whatever the browser's TextDecoder supports, which is the full WHATWG Encoding list — the 25 in the table are the ones that turn up in real URLs. Any the browser refuses are skipped rather than shown as failures.
Is my data sent anywhere?
No. TextDecoder is built into the browser, so decoding happens locally with no request.