Encoding Explorer

How it works

Paste any string — encoded or plain — and the explorer instantly tries to decode it as URL percent-encoding, Base64, HTML entities and Quoted-Printable at the same time. Every decoding that produces sensible text appears in its own box, and the format that most likely produced your string gets a most likely badge. Below that, the same input is shown encoded in all four formats, updating live as you type. Everything runs locally in your browser; nothing is uploaded.

Paste encoded text to decode it

This is the tool's main use: you find a mysterious string — in a JWT, a query string, an email source, a config file — and you paste it here. A Base64 value like SGVsbG8gRG9jdVplcm8h immediately shows Hello DocuZero! under Base64 — decoded, with the badge confirming Base64 is the likely format. A URL fragment like Caf%C3%A9%20latte decodes as URL encoding. URL-safe Base64 (with - and _) is accepted too, as are line-wrapped Quoted-Printable bodies. Decoders are strict: if a format wouldn't produce valid readable text, its box simply stays hidden rather than showing garbage.

A concrete example

Start from the pre-filled sample SGVsbG8gRG9jdVplcm8h. Only the Base64 box lights up — it decodes to Hello DocuZero! and earns the most likely badge, because a plain Base64 block contains no % pairs, no &name; tokens and no =XX escapes for the other three decoders to latch onto. Replace it with Caf%C3%A9%20latte and the URL box decodes Café latte; type Schröder and the HTML-entities box renders Schröder, exactly as a browser would parse it.

Now paste plain text instead — say Tom & Jerry — café 🚀 — and watch the encoded-forms section build all four representations side by side. HTML entities keep the text readable and escape only & plus the non-ASCII letters (café), URL encoding turns every special character into a %XX escape, Base64 scrambles the whole thing into a block of letters and digits, and Quoted-Printable stays close to the original with just a few =C3=A9-style escapes. It's the fastest way to see how each format transforms the same text.

The four encodings

HTML entities make text safe to place inside a web page. URL encoding makes it safe inside a link or query string. Base64 turns any data into plain letters and digits, common in data URIs, tokens and email attachments. Quoted-Printable is the mostly-readable encoding used in email bodies. Seeing them together highlights the differences: Base64 obscures the text entirely, while the other three keep readable characters and only escape the tricky ones.

You can also learn to recognize them by shape. Lots of %20-style pairs means URL encoding; &-style semicolon tokens mean HTML entities; a long block of only letters, digits and +/= (or -_) means Base64; stray =3D-style pairs plus = at line ends mean Quoted-Printable. The explorer does this recognition for you, and when more than one decoding succeeds the most unambiguous pattern — judged by how distinctive each format's syntax is — wins the most likely badge.

Common problems and fixes

No decoded box appears. The input probably isn't encoded in any of the four formats — plain text stays plain, and decoding only runs once the pasted string is at least 4 characters long. A value that should decode shows nothing. The decoders are strict and skip anything that wouldn't produce valid UTF-8 text, so malformed or truncated input is ignored instead of displayed as garbage. My Base64 has spaces or URL-safe characters. That's fine — whitespace is stripped and -/_ are translated automatically before decoding. The URL-encoded box shows an Error: message. That only happens with input the standard encoder rejects, such as an unpaired surrogate; fix the offending character and the form re-encodes instantly. And if you're handling something sensitive, remember every character is processed live in your browser — nothing you paste ever leaves the device, so you can explore JWT payloads, config tokens and email source without worry.

Frequently asked questions