Base64 & URL Encoder

The four schemes and what each is for

Standard Base64 represents binary as 64 printable characters, using A–Z, a–z, 0–9, plus and slash, with equals signs as padding. It exists so binary data can travel through systems that only handle text — email attachments, JSON string fields, data URIs.

Base64URL replaces plus with hyphen and slash with underscore, and usually drops the padding. Those two substitutions matter because plus and slash have special meanings in URLs and would otherwise need escaping. This is the variant used inside JSON Web Tokens.

URL encoding (encodeURI) escapes characters that are not valid in a URL while leaving the structural characters — colon, slash, question mark, ampersand — intact. Use it on a complete URL.

URL component encoding (encodeURIComponent) escapes those structural characters too. Use it on a value you are inserting into a query string, since a value containing an ampersand would otherwise be read as the start of a new parameter. Choosing the wrong one of these two is a persistent source of broken links.

Why naive Base64 breaks on Unicode

The browser's built-in btoa function only accepts characters in the range 0–255. Feed it an emoji, a Chinese character, or an accented letter above that range and it throws an error rather than encoding it.

The correct approach, which this tool uses, is to encode the text as UTF-8 bytes first and Base64 those bytes. Decoding reverses it: Base64-decode to bytes, then interpret those bytes as UTF-8.

This is why some Base64 tools mangle non-English text and this one does not. If you have ever seen a decoded string come back as garbled characters, a missing UTF-8 step was almost certainly why.

Base64 is not encryption

This is worth stating plainly because the misconception is widespread and occasionally expensive. Base64 is a reversible text representation with no key and no secret. Anyone who can see the encoded string can decode it in one step.

A JSON Web Token illustrates the point neatly. Its header and payload are Base64URL-encoded, not encrypted — you can paste the middle section into this tool and read the claims. What makes a JWT trustworthy is the cryptographic signature on the end, which proves the payload has not been altered. It does nothing to hide it.

So: never put a secret in a Base64 string and consider it protected, and never treat data as validated because it arrived Base64-encoded.

The size overhead

Base64 encodes three bytes as four characters, so encoded data is about 33% larger than the input, plus padding. That is the price of passing binary through a text-only channel.

It is why email attachments are noticeably larger in transit than on disk, and why inlining images as data URIs should be reserved for small files. It is also why, for anything sizeable, compressing before encoding is worth doing — the overhead applies to whatever you feed in.

For URL encoding the overhead is variable: each escaped character becomes three characters, so a string of mostly safe characters barely grows while one full of spaces and symbols can triple.