Base64 Variants Reference

Standard, URL-safe, MIME and other Base64 alphabets and padding rules.

Reference and live encoder for Base64 variants: RFC 4648 standard and URL-safe alphabets, MIME line-wrapping, IMAP modified base64 and a base32 comparison, showing how the same input encodes under each.

What is the difference between standard and URL-safe Base64?

Both use the same 64-symbol scheme, but standard Base64 (RFC 4648 §4) uses + and / for values 62 and 63, while URL-safe Base64 (§5) uses - and _ so the output is safe in URLs and filenames without percent-encoding.

Base64 variants explained

Base64 encodes arbitrary binary data into ASCII text using 64 printable symbols. Several variants exist that differ in their alphabet (especially the last two symbols), their padding rules, and whether they wrap lines. This reference describes each variant and includes a live encoder so you can see how the same input renders under standard, URL-safe and other schemes.

How it works

Base64 reads the input three bytes (24 bits) at a time and splits those 24 bits into four 6-bit groups. Each group (0–63) indexes into a 64-character alphabet, producing four output characters. Three input bytes always become four output characters, which is why output is roughly 33% larger than the input.

The alphabets share characters for values 0–61 (A–Z, a–z, 0–9) and differ only at 62 and 63:

  • Standard (RFC 4648 §4) uses + and /.
  • URL-safe (RFC 4648 §5) uses - and _, avoiding characters that need escaping in URLs.

Padding: when the final group has only one or two bytes, the output is padded with = so its length is a multiple of four. URL-safe Base64 (e.g. in JWTs) usually drops the = to keep tokens clean. MIME (RFC 2045) uses the standard alphabet but breaks output into 76-character lines. For contrast, Base32 (RFC 4648 §6) uses a 32-symbol alphabet, expanding data by about 60%.

Tips and example

Encoding the bytes of Gera>? shows the alphabet difference at positions 62/63:

input        Gera>?
standard     R2VyYT4/
url-safe     R2VyYT4_

For tokens that travel in URLs, headers or filenames, always pick URL-safe Base64 and strip padding, then re-add it when decoding if your library requires it. Never assume an arbitrary Base64 string is valid in a URL — +, / and = all need percent-encoding. Type in the box below to compare every variant on your own input.