Encoder / Decoder

Convert text between Base64, Base64URL, URL encoding, HTML entities and hex, in either direction. The everyday tool for making sense of a mangled value in a log or a query string.

Base64 and URL encoding are often described as ways to hide data. They are not — both are reversible by anyone, with no key involved. What they do is make arbitrary bytes survive a channel that only tolerates certain characters: an email header, a query string, an HTML attribute.

The distinctions that actually cause bugs are handled explicitly here. Base64 and base64url differ in two characters and in padding, so a JWT segment will not decode with the standard alphabet. encodeURIComponent escapes the separators &, = and ?, while encodeURI deliberately leaves them alone, which is why one is right for a parameter value and the other for a whole URL. Everything is UTF-8, so non-ASCII text round-trips instead of turning into question marks.

Base64 turns three bytes into four characters, so anything encoded with it grows by a third before padding is counted. That is why inlining a photograph as a data URI bloats a stylesheet, and why a base64 field is a poor way to move a large file through a JSON payload. The equals signs at the end are padding to a multiple of four: some decoders require them and others tolerate their absence, which is exactly why a token copied without its trailing padding fails in one place and works in another. base64url, the variant JWTs and URL parameters use, replaces two characters of the alphabet and drops the padding by convention, so a segment that will not decode under the standard alphabet is usually not corrupt at all.

Encoded output is not always a single line, and the line breaks are load-bearing. MIME wraps base64 at 76 characters; PEM, the format certificates and private keys arrive in, wraps at 64 — both with real newlines inside the data. A decoder written for one continuous line rejects those, so a value pasted straight out of a certificate file usually needs its breaks removed first. The mistake runs in the other direction too: an encoder that inserts wrapping where the destination did not expect it produces a value that fails validation for a reason invisible on screen, because the difference between the working string and the broken one is a character that draws nothing.

Percent-encoding and HTML entity encoding solve different problems and are frequently needed at the same time. A query string sitting inside an href attribute has to survive both the URL parser and the HTML parser, so an ampersand becomes %26 when it is part of a value and & when it is separating two parameters — encode for the wrong layer and the link silently loses everything after that point. Space is the other routine trap: %20 is always correct, while a plus sign means a space only in application/x-www-form-urlencoded. In a path segment a plus is a literal plus, which is how a filename containing one goes missing between the browser and the server.

The JavaScript function most people reach for cannot encode Korean at all. btoa operates on Latin-1 and throws on any character above U+00FF, so passing it Hangul, an emoji or a curly quote produces an exception rather than a wrong answer — and the workaround that turns up in old answers, escaping the string first, mangles multi-byte characters in a way that only shows up later. The correct route is to encode the text as UTF-8 bytes and base64 those, which is what happens here. It is the reason non-ASCII text round-trips through this page and comes back exactly as it went in.