Standard Base64 vs Base64URL Encoding

Base64 is the go-to standard for transmitting binary data over text-based protocols. However, the standard Base64 alphabet contains two characters that are strictly reserved in URLs and file systems: the plus sign (+) and the forward slash (/).

To solve this, a specialized variant called Base64URL (often referred to as URL-safe Base64) was introduced in RFC 4648.

The Problem with Standard Base64 in URLs

Imagine you want to send a Base64-encoded security token in a URL query parameter:

https://example.com/verify?token=aGVsbG8rc2VjcmV0/ZGF0YQ==

This URL will almost certainly break when processed by the server, because:

• The Plus Sign (+): In URL query strings, a + is historically interpreted as a space character. When your server decodes the query parameter, aGVsbG8rc2VjcmV0/ZGF0YQ== becomes aGVsbG8 c2VjcmV0/ZGF0YQ==, which is corrupt and invalid Base64.
• The Forward Slash (/): If you try to place the token in the URL path (e.g., /api/users/aGVsbG8rc2VjcmV0/ZGF0YQ==), the web server will treat the / as a directory separator, resulting in a 404 Not Found error.

The Solution: Base64URL

The Base64URL encoding scheme solves these problems by making exactly two substitutions to the standard Base64 alphabet:

• The + character (Index 62) is replaced with a minus sign (-).
• The / character (Index 63) is replaced with an underscore (_).

What about the Padding (=)?

Standard Base64 uses the equals sign (=) for padding at the end of the string. While the equals sign is technically a safe character in a URL path, it carries special meaning in query strings (e.g., separating keys from values like key=value).

Because of this, Base64URL implementations typically omit the padding characters entirely. Since the length of the string is known, the decoder can dynamically calculate the missing padding and safely decode the string without the equals signs.

JSON Web Tokens (JWT)

If you work with modern web authentication, you are already using Base64URL.

A JSON Web Token (JWT) is composed of three parts separated by periods (.). The Header, Payload, and Signature are all encoded exclusively using Base64URL (with no padding). This guarantees that JWTs can be passed seamlessly in HTTP Headers (Bearer tokens), URL parameters, or POST bodies without requiring additional URL-encoding wrappers.