Base64URL

Why a second variant exists

Base64 turns arbitrary bytes into text using 64 characters, and three bytes become four characters. It is an encoding, not encryption: it hides nothing, and anyone can reverse it instantly. Its last two symbols, though, are awkward outside plain text.

What changes in the URL-safe variant

Standard Base64 uses + and / as its last two symbols and = for padding. All three have special meanings in URLs and filenames. Base64URL fixes that:

	Standard Base64	Base64URL
Symbol 62	+	-
Symbol 63	/	_
Padding	= (required)	= (usually omitted)

The bytes 0xFB 0xFF 0xFE show the difference. Standard Base64 gives +//+ and Base64URL gives -__-.

Padding exists only so the encoded length is a multiple of four. The decoder can work the length out on its own, so JWTs and most URL uses leave it off. Hello is SGVsbG8= with padding and SGVsbG8 without.

Where you will meet it

• JWTs: the header, payload and signature are each Base64URL-encoded.
• URLs and filenames: tokens, IDs and small blobs of data.
• PEM files use standard Base64, not the URL-safe variant.

Common pitfalls

• Mixing the variants. Feeding a Base64URL string to a standard decoder fails or produces garbage as soon as a - or _ appears. Convert first by replacing - with + and _ with /, then re-adding padding.
• Browser atob/btoa and Unicode. They operate on Latin-1 “binary strings”, not UTF-8. To encode text with non-ASCII characters, convert it to UTF-8 bytes first.
• Forgetting the size cost. Embedding a 3 MB file as Base64 adds about 1 MB.
• Assuming it is secret. A Base64 string in a token or config file is readable by anyone who sees it.