Base64 vs URL encoding: when to use which

Base64 and URL encoding (also called percent encoding) both turn data into "safe" characters, so they are easy to mix up. They solve different problems. Base64 turns any bytes, including images and binary data, into plain text. URL encoding keeps text intact inside a URL or a form by escaping the characters that have a special meaning there. Neither one hides or protects data.

Base64 in short

Base64, defined in RFC 4648, takes bytes three at a time and writes each group as four characters from an alphabet of 64: A to Z, a to z, 0 to 9, + and /. When the input does not divide evenly into groups of three, one or two = signs pad the end. The result is about a third larger than the input.

Use Base64 when you need to carry bytes through a channel that only accepts text: an image inside a data URL, a file attachment in an email, a binary key in a JSON field, or a credential in an HTTP header that expects text.

URL encoding in short

URL encoding, defined for URIs in RFC 3986, leaves letters, digits and a few symbols (- . _ ~) as they are and writes every other byte as a percent sign followed by two hexadecimal digits. A space becomes %20, & becomes %26, and a letter such as é becomes its UTF-8 bytes, %C3%A9.

Use URL encoding when you put a value into a URL, for example a search term in a query string or a name in a path. Without it, a value containing &, =, ?, # or / would be read as part of the URL's structure.

Side by side

The plus sign and the space

HTML forms sent as application/x-www-form-urlencoded write a space as + instead of %20. That is why a plus sign in a query string is often read as a space, and why a real plus sign must be sent as %2B. Standard Base64 also uses +, so a Base64 value put into a URL without encoding can lose its plus signs and stop decoding.

URL-safe Base64

RFC 4648 also defines a URL- and filename-safe alphabet that uses - instead of + and _ instead of /. The padding = is often left out as well. JSON Web Tokens use this form for each of their three parts, which is why a token can sit in a URL or a header without any further encoding. If a Base64 value fails to decode, check whether it is the URL-safe form and whether padding was removed.

Neither is encryption

Anyone can decode Base64 or URL encoding without a key. A password, an API key or personal data written in Base64 is not protected. To keep data secret, use encryption; to prove data was not changed, use a signature such as an HMAC. The API Payload Inspector shows how easily the content of a token can be read once you have it.

Which one should you use?

• A search term, name or ID in a URL: URL encoding of that value only. Do not encode the whole URL with the value-level function, or the : and / of the address are escaped too.
• An image or file inside JSON, CSS or HTML: Base64.
• Binary data in a URL: URL-safe Base64, or standard Base64 followed by URL encoding.
• Text that already contains % sequences: decode once and check before you encode again, to avoid double encoding such as %2520.

Try both on the same text with the Base64 Encoder & Decoder and the URL Encoder & Decoder to see the difference for yourself.