Base64 vs Base64URL: What's the Difference?
The Purpose of Base64
To understand the difference, we first must understand the goal. Base64 is an encoding scheme used to represent binary data in an ASCII string format. It is essential when you need to send binary data (like an image, or compiled code) over media that are designed to deal primarily with text, such as HTTP headers or JSON payloads.
Standard Base64 translates binary data into a 64-character alphabet consisting of the uppercase and lowercase English alphabet (A-Z, a-z), numbers (0-9), the plus sign (+), and the forward slash (/). It also utilizes the equals sign (=) as a special padding character at the end of the string.
The URL Collision Problem
Standard Base64 works perfectly for embedding images in HTML or sending attachments in emails. However, it completely falls apart when you try to send the encoded data via a URL query parameter or a strict HTTP header.
Consider a URL like this: https://api.example.com/verify?token=aB3+c/d==
When a web server processes this URL, it encounters severe parsing conflicts:
- The
+sign is historically interpreted by URL decoders as a "space" character. - The
/character is fundamentally understood as a directory or path separator. - The
=character is universally recognized as the delimiter between keys and values in query strings.
The Base64URL Solution
To circumvent these fatal parsing errors, RFC 4648 standardized the Base64URL encoding scheme. It is structurally identical to standard Base64, but it makes three surgical modifications to the character alphabet to ensure the output is entirely URL-safe and filename-safe:
- Every
+is replaced with a-(minus). - Every
/is replaced with an_(underscore). - The
=padding characters at the end of the string are completely stripped away.
Why JWTs Demand Base64URL
Because JSON Web Tokens are explicitly designed to be transmitted in HTTP Authorization headers, deep-link URLs, and cross-domain query parameters, the JWT specification strictly mandates the use of Base64URL encoding.
If you attempt to write a script that parses a JWT using a standard Base64 decoder, it will crash as soon as it encounters a - or an _, or it will throw an exception due to the missing = padding. This is why specialized tools like TokenDecode are necessary—they natively understand the URL-safe variant and handle the padding reconstitution automatically behind the scenes.