Base64 vs Base64URL: When to Use Each Encoding

The Short Answer

Base64URL is Base64 with two character substitutions that make it safe for URLs and filenames. Standard Base64 uses + and /, which conflict with URL syntax. Base64URL replaces them with - and _.

If you are putting encoded data into a URL, query parameter, filename, or JWT token, use Base64URL. If you are storing or transmitting data in non-URL contexts, standard Base64 is fine.

The Character Sets Side by Side

Standard Base64 and Base64URL share 62 of their 64 characters:

The encoding logic is identical. The only difference is which two characters represent indices 62 and 63.

Why Standard Base64 Breaks in URLs

In URLs defined by RFC 3986:

• + is an alias for space in query strings (application/x-www-form-urlencoded)
• / separates path segments

When standard Base64 output contains + or /, a URL parser misinterprets them:

Input:  "Hello, World!"
Base64:  SGVsbG8sIFdvcmxkIQ==
          ^^              ^^
          + (space in query)  / (path separator)

Base64URL: SGVsbG8sIFdvcmxkIQ==
           --              --
           - (literal dash)   _ (literal underscore)

Padding Behavior

Both encodings use = to pad the output to a multiple of 4 characters. However, Base64URL implementations often omit padding:

import base64

data = b"Hello"

# Standard Base64 - with padding
base64.b64encode(data)        # b'SGVsbG8='

# Base64URL - with padding
base64.urlsafe_b64encode(data)  # b'SGVsbG8='

# Base64URL - without padding (common in JWTs)
base64.urlsafe_b64encode(data).rstrip(b'=')  # b'SGVsbG8'

Padding characters can cause issues in URL contexts (some frameworks strip = from URLs) and in JWT tokens (where the segments must not contain padding per RFC 7515). Whether you need padding depends on the consumer:

• JWT: no padding
• AWS SigV4: no padding
• Data URLs: padding required
• Binary protocol wrappers: usually padding required

When to Use Each

Use standard Base64 when:

• Encoding data for email (MIME, RFC 2045)
• Embedding binary data in XML or JSON where URL safety is irrelevant
• Storing data in databases or configuration files
• Displaying encoded data in a UI (the + and / characters are more recognizable)

Use Base64URL when:

• Putting encoded data in a URL path or query parameter
• Generating JWT tokens
• Creating OAuth PKCE code verifiers
• Encoding data that will appear in a filename
• Any context where + or / could be misinterpreted

Converting Between Formats

The conversion is reversible with no data loss:

Standard Base64 → Base64URL:
  1. Replace '+' with '-'
  2. Replace '/' with '_'
  3. Optionally strip trailing '=' padding

Base64URL → Standard Base64:
  1. Replace '-' with '+'
  2. Replace '_' with '/'
  3. Re-add '=' padding until length is a multiple of 4

// JavaScript conversion examples

// Base64 to Base64URL
function toBase64Url(base64) {
  return base64.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
}

// Base64URL to Base64
function fromBase64Url(base64Url) {
  let base64 = base64Url.replace(/-/g, '+').replace(/_/g, '/');
  while (base64.length % 4) base64 += '=';
  return base64;
}

Gotchas

Double encoding. If you Base64-encode data that is already Base64-encoded, you get a longer string with no benefit. Check whether your input is already encoded before applying another round.

Line breaks. Standard Base64 in email (MIME) inserts line breaks every 76 characters. URL-safe contexts must not contain line breaks. Strip them if converting from email-format Base64.

Character encoding of the input. Both encodings operate on raw bytes, not characters. If you encode a UTF-8 string, the bytes are what matter. Decoding produces the same bytes, which you then interpret as UTF-8. Mixing character encodings (e.g., encoding UTF-16 bytes but decoding as UTF-8) produces garbage.

Not encryption. Base64 (both variants) is an encoding, not encryption. The original data is trivially recoverable by anyone who sees the encoded string. Do not use it to protect sensitive data.