URL-safe Base64, explained.

The problem

Standard Base64 uses two characters that have special meaning on the web: + and /. In a URL, + can be interpreted as a space, and / separates path segments. If you put a standard Base64 string into a URL, it may get mangled by web servers, proxies, or browsers before it reaches your code.

The fix

URL-safe Base64 (defined in RFC 4648 §5) swaps those two characters out:

Standard	URL-safe
+	- (hyphen)
/	_ (underscore)
= padding	often omitted

Both hyphen and underscore are URL-safe in every context — paths, query strings, fragments, filenames. The character set is otherwise identical.

Padding: usually dropped

The = character is technically URL-safe, but it's often dropped from URL-safe Base64 anyway. JWTs drop it. base64url in most languages drops it. The reason: the padding is redundant — you can always recompute it from the string length. If the length mod 4 is 2, add ==; if it's 3, add =; if it's 0, no padding needed.

This is why JWT tokens look like eyJhbGciOi... with no trailing equals signs.

Where URL-safe Base64 shows up

• JWTs. Each of the three segments (header, payload, signature) is URL-safe Base64, no padding. (JWT decoding guide.)
• OAuth 2.0. PKCE code challenges, state parameters, and many access tokens use URL-safe Base64.
• Cookie values. Some frameworks encode signed cookies as URL-safe Base64 to avoid escaping inside Set-Cookie headers.
• File names. A hash that needs to become a filename is often URL-safe Base64 — no / means no accidental directory traversal.
• S3 object keys. Standard Base64 with / would create unintended folder hierarchies in S3.

Detecting which variant you have

If the string contains - or _, it's URL-safe. If it contains + or /, it's standard. If it contains neither (only letters, digits, and possibly =), it could be either — and any compliant decoder will produce the same output.

Converting between variants

If you ever need to convert by hand:

• Standard → URL-safe: replace + with -, / with _, and optionally strip trailing =.
• URL-safe → Standard: replace - with +, _ with /, and pad with = until the length is a multiple of 4.

Common pitfall

Mixing variants is the #1 source of "invalid Base64" errors when one system encodes URL-safe and another expects standard. The fix is to normalize before decoding. Almost every modern Base64 library has a "permissive" mode that accepts both — use it unless you have a reason not to.

Try it

Paste a JWT into the decoder, with or without the trailing equals signs, and watch it work either way.

---

Published May 2026 · Last reviewed May 2026. Spot an error? Email contactus@base64decode.tools.