URL-safe Base64 vs standard Base64: why your JWT tokens need the variant
Standard Base64 uses + and / in its 64-character alphabet. Those characters have special meaning in URLs (+ is a space in query strings, / is a path separator), so putting standard Base64 in a URL requires percent-encoding. URL-safe Base64 (RFC 4648 §5) replaces + with - and / with _, making the output safe to drop directly into a URL path or query string without any encoding.
How this is calculated
JWT tokens use URL-safe Base64 for all three segments (header, payload, signature). Without it, every JWT would need to be percent-encoded before appearing in an Authorization: Bearer header or a query parameter. URL-safe Base64 also commonly omits the = padding characters, since the encoded length can be inferred from the string length. JavaScript's btoa() produces standard Base64. To get URL-safe, replace + with -, / with _, and strip trailing =. Most JWT libraries handle this automatically, but if you're hand-rolling token generation, this is the most common mistake.
Verdict
Use URL-safe Base64 for anything that appears in a URL: JWT tokens, OAuth state parameters, verification tokens in emails, and data URIs embedded in SVG. Standard Base64 is for everything else: JSON payloads, MIME attachments, and storage.
