Base64 vs Base64URL: What's the Difference and When to Use Each

Base64 and Base64URL encode the same bytes the same way — the alphabet is nearly identical. Only two characters change and padding becomes optional. That sounds trivial, until an encoded string silently breaks a URL, a file name or a JWT. This article shows exactly where they differ and which one you should use.

Base64

A binary-to-text encoding that maps 3 input bytes to 4 ASCII characters using a 64-character alphabet (A–Z, a–z, 0–9, + and /), padded to a multiple of 4 with = signs.

Base64URL

The URL-safe variant of Base64 defined in RFC 4648: + becomes -, / becomes _, and trailing = padding is usually removed so the string is safe in URLs, file names and headers.

Padding (=)

The = signs appended to a Base64 string when its length isn't a multiple of 3. Base64URL can omit them because the recipient can infer the missing padding from the length.

Percent-encoding

The URL escaping scheme that turns characters like + and / into %2B and %2F. Standard Base64 must be percent-encoded inside query strings; Base64URL does not need to be.

The two characters that differ

Both alphabets share the first 62 characters: A–Z, a–z and 0–9. The difference is in the last two slots and the trailing padding:

Why those two characters matter

• In a query string, + is decoded as a space by most server frameworks, so payloads get corrupted.
• In a path or file name, / is a directory separator — it would create subdirectories.
• Percent-escaping + and / as %2B and %2F works, but it inflates the string and is easy to forget.
• Base64URL's - and _ are safe almost everywhere: URLs, file names, headers and JWT segments.

The rule of thumb: if the encoded text will ever live in a URL, a file name, a cookie or an HTTP header, use Base64URL. If it's stored in a database or payload body where +, / and = are fine, standard Base64 is acceptable.

Padding: required vs optional

Standard Base64 pads its output to a multiple of 4 with = characters, so length is always divisible by 4. Base64URL removes the padding — the decoder infers it from length modulo 4. That's why JWT segments usually have no = at the end.

Input (3 bytes): 0x68 0xF8 0x7E

Standard Base64: hLg/eA==
Base64URL:      hLg_eA

Where Base64URL is effectively mandatory

• JWTs — header, payload and signature are base64url-encoded so a token survives in an Authorization header and query strings.
• Data URIs — an inline image as data:image/png;base64, uses standard Base64 inside the URI value.
• CDN and storage keys — file-like identifiers for object storage should use Base64URL to avoid slashes.
• OAuth parameters — state and verifier values often travel percent-encoded; Base64URL keeps them compact.

Converting between the two

1. Paste the string into the Base64 Decoder — it handles standard and URL-safe input.
2. If you switch encodings in code, translate the alphabet explicitly: + to -, / to _, and restore padding by length.
3. For JWTs, use the JWT Decoder, which decodes the three base64url segments as one token.