URL-safe Base64 vs standard Base64: why your JWT tokens need the variant
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.
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.
By TechCompare · Updated
How this is calculated
JWT tokens use URL-safe Base64 for all three segments (header, payload, signature). JOSE requires unpadded Base64url for these segments. That is a token-format rule, not a restriction of the Authorization header: RFC 6750 permits +, /, and trailing = in Bearer credentials without percent-encoding. URL components have separate escaping rules. 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
Standard Base64 leaks two characters that break in URLs: + reads as a space in query strings and / is a path separator. RFC 4648 §5 swaps them for - and _ so the output drops in cleanly. JWT encodes all three segments this way, and trailing = padding is usually stripped since the length implies it. JavaScript's btoa() still emits standard output, so swap manually or use a library.