Base64 vs. Base64URL: Why JWTs Use a Different Alphabet

Base64URL is standard Base64 with two characters swapped and padding dropped: + becomes -, / becomes _, and the trailing = padding is omitted. The decoded bytes are identical either way — only the alphabet and padding differ, and that's specifically to make the output safe to drop into a URL, HTTP header, or cookie without escaping.

Why the swap matters

Standard Base64's + and / characters have special meaning in URLs (+ can mean a space in query strings, / is a path separator), so a standard Base64 string dropped into a URL without percent-encoding can get silently corrupted or misparsed. Base64URL avoids the problem entirely by never using those characters in the first place.

Why JWTs specifically use it

RFC 7515 (the JSON Web Signature spec) mandates unpadded Base64URL for all three JWT segments — header, payload, and signature — precisely because JWTs are routinely transmitted in Authorization headers, URL query parameters, and cookies. A token encoded with standard Base64 would need extra escaping to survive those contexts safely; Base64URL sidesteps that requirement entirely.

Decoding either one

If you're writing your own decoder rather than using a library, the fix for reading Base64URL is one step: replace - with +, _ with /, then re-add = padding until the length is a multiple of 4, and it decodes with a standard Base64 routine. This is exactly why a JWT decoder can't just call a generic Base64 decode function without that translation step first.