Free Encoder & Decoder Tools

Q: Why does my decoded base64 look like binary garbage?

Because it probably is. Base64 carries no type information, so a PNG or gzipped payload decodes to raw bytes that are meaningless as text. Check the first decoded characters: PK is a zip, %PDF is a PDF.

Q: Should I encode the whole URL or just the parameter values?

Just the values. A full URL run through a percent encoder turns :// and ? into %3A%2F%2F and %3F, giving one long invalid path. Encode each value, then assemble.

Q: Do I need HTML entities for every non-ASCII character?

No. If the page declares <meta charset="utf-8">, write accented letters and symbols directly. Reserve entities for the characters that carry markup meaning, plus for a non-breaking space.

Encode and decode the formats that move data between systems: Base64, URL percent-encoding, HTML entities. Browser-side, no logging.

📝Base64 Encode / DecodeEncode text to Base64 or decode Base64 back to text. 🔗URL Encode / DecodePercent-encode and decode URL parameters and paths. 🔤HTML Entities EncodeEscape and unescape HTML entities — & < > etc. 🖼️PNG to Base64Encode images as data URIs. 🔓Base64 to PNGDecode data URIs back to images.

Picking the right encoding for the layer you are in

Most encoding bugs come from applying the wrong scheme, or the right one twice. The three tools here map to three layers of a request and are not interchangeable.

Base64 rewrites arbitrary bytes using a 64-character ASCII alphabet, with = as padding. Use it when something that expects text has to carry binary: an image in a data URI, a certificate in PEM form, an attachment inside a MIME email. Every three bytes become four characters, so the payload grows about a third before padding: hello encodes to aGVsbG8=.

Percent encoding escapes characters that have meaning inside a URL. A space becomes %20, an ampersand in a query value becomes %26, and a slash inside a path segment becomes %2F. If you skip it, ?q=fish&chips silently splits into two parameters and the value you wanted is gone.

HTML entity encoding stops browser markup from swallowing your text. < becomes <, & becomes &, a quote inside an attribute becomes ". Encoding at output time is how a stray <script> in a username stops being executable.

Signs you have encoded twice

Double encoding is the most common failure and it has a visible signature. In a URL you see %2520: something encoded a space to %20, then encoded that percent sign again as %25. In HTML the source reads &lt;, so the page prints the literal text < instead of a <. Decode once, read the result, and decode again only if it still looks encoded.

Base64 variants that trip people up

URL-safe alphabet. JWTs and many APIs use base64url, which swaps + for -, / for _, and usually drops the = padding. Strict decoders reject it.
Padding. A padded string is always a multiple of 4 characters. A remainder of 2 or 3 means the = signs were stripped and you can add them back; a remainder of 1 is never valid base64, so the string is truncated.
Line breaks. PEM wraps at 64 columns, MIME at 76. Those newlines belong to the format, not corruption, but a strict decoder rejects them.

Encoding characters that are not ASCII

Percent encoding operates on bytes, not characters, so the character set matters before the encoding does. Under UTF-8, é is two bytes and encodes to %C3%A9. Under Latin-1 it is one byte, %E9. Both are legal; only one matches what the receiving server expects. If names come back as Ã© or Â£, the bytes are fine and the declared charset is wrong.

Base64 has the same trap: encode a UTF-8 string in one runtime, decode it as Latin-1 in another, and you get mojibake with no error raised.

Where these tools run

Every encoder here runs in your browser tab, which matters when the thing you are decoding is a JWT carrying a customer id, a basic auth header, or a database URL out of a stack trace. Open devtools, watch the network panel while you paste: nothing leaves.

Common questions

Why does my decoded base64 look like binary garbage? Because it probably is. Base64 carries no type information, so a PNG or gzipped payload decodes to raw bytes that are meaningless as text. Check the first decoded characters: PK is a zip, %PDF is a PDF.

Should I encode the whole URL or just the parameter values? Just the values. A full URL run through a percent encoder turns :// and ? into %3A%2F%2F and %3F, giving one long invalid path. Encode each value, then assemble.

Do I need HTML entities for every non-ASCII character? No. If the page declares <meta charset="utf-8">, write accented letters and symbols directly. Reserve entities for the characters that carry markup meaning, plus   for a non-breaking space.

Is a JWT encrypted? No. Header and payload are base64url encoded and readable by anyone holding the token; only the signature proves it has not been altered. Base64 is not encryption anywhere else either, so keep passwords and secrets out of claims.

Why use browser-side encoders?

Encoding tools often handle sensitive data — API tokens, OAuth credentials, customer-identifying strings, internal IDs. Pasting that into a server-based encoder is a privacy risk. The tools here process text entirely in your browser; nothing is uploaded or logged.