Base64 vs Base64 URL

The two-character difference

Both encodings turn 3 input bytes into 4 output characters from a 64-character alphabet. They differ on two characters:

That's it. Same 0–61 (A–Z, a–z, 0–9), same encoding algorithm, same decoded output. The two-character swap exists so the result is safe to drop into a URL path or query string without further escaping.

When to use which

Use Base64 (standard) for…

• Email attachments — MIME content-transfer-encoding has used standard Base64 for decades.
• Binary data in JSON or XML — APIs that embed images, PDFs, or other binary in a text payload almost always use standard Base64.
• Data URIs — data:image/png;base64,... uses standard Base64.
• Anything where you control the transport and don't need URL safety.

Use Base64 URL for…

• JWTs — every part of a JSON Web Token is Base64 URL encoded with padding stripped.
• OAuth 2.0 tokens, PKCE code challenges — RFC 7636 mandates Base64 URL.
• URL-safe IDs — short hashes, share links, signed cookies that travel as path or query parameters.
• WebPush keys — VAPID keys are Base64 URL by spec.
• Anywhere the encoded value is going inside a URL and you don't want to double-escape.

Why the standard Base64 characters break URLs

URLs interpret several Base64 characters as control:

• + — in application/x-www-form-urlencoded (the format used by most form submissions), + means a space. So a Base64 string like aGVsbG8+ becomes aGVsbG8 (with a space) when read by a server expecting form-encoded input.
• / — splits a URL path into segments. A Base64 string containing / dropped into a path will be parsed as multiple path segments.
• = — separates query keys from values. Trailing = padding can confuse query string parsers.

Base64 URL avoids all three by mapping the two problematic alphabet characters to - and _ (which are valid in URLs without escaping) and dropping padding entirely.

Converting between them

The transform is mechanical:

// standard → URL
const urlSafe = standard
  .replace(/\+/g, "-")
  .replace(/\//g, "_")
  .replace(/=+$/, "");

// URL → standard
const padded = urlSafe + "=".repeat((4 - urlSafe.length % 4) % 4);
const standard = padded.replace(/-/g, "+").replace(/_/g, "/");

Our encoder does the conversion for you — paste a Base64 URL string into the Base64 URL tab and decode, or paste a standard Base64 string into the Base64 tab.

Quick reference: decoding a JWT

A JWT is three Base64 URL segments joined by dots:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxIn0.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

To peek at the contents:

1. Split on . — three segments.
2. Decode segment 1 (header) as Base64 URL → JSON. Tells you the algorithm.
3. Decode segment 2 (payload) as Base64 URL → JSON. Your claims.
4. Segment 3 is the signature — binary, used only for verification.

Important: decoding only proves what the token claims. Always verify the signature server-side before trusting any claim from a JWT.

Reference

• RFC 4648 — Base64, Base64 URL, Base32, Base16. The current standard.
• RFC 7519 — JWT, which mandates Base64 URL for all three segments.
• RFC 7636 — PKCE, also Base64 URL.

FAQ

Open the encoder →