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.

Why does Base64 use = padding?

Base64 encodes 3 input bytes into 4 characters. When the input length is not a multiple of 3, one or two = characters pad the final group so the output length is a multiple of 4. Some variants omit padding entirely.

MIME Base64 (RFC 2045) uses the standard alphabet but wraps the output into lines of at most 76 characters separated by CRLF, and decoders must ignore characters outside the alphabet, including the line breaks.

What is modified Base64 for IMAP?

IMAP's UTF-7 mailbox names (RFC 3501) use a modified Base64 that keeps + and replaces / with a comma, and omits padding. It encodes only the non-ASCII portions of mailbox names between & and - delimiters.

How much larger is Base64 output than the input?

Base64 expands data by about 33%, since every 3 bytes become 4 characters. With padding and MIME line breaks the overhead is slightly higher. Base32 expands more, by about 60%.

What is the Base64 Variants Reference?

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. It runs free in your browser on Gera Tools, with nothing uploaded.

Base64 Variants Reference

Name: Base64 Variants Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

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%.

All variants at a glance

Variant	Standard chars 62/63	Padding	Line wrap	RFC
Standard Base64	`+` `/`	`=`	None	RFC 4648 §4
URL-safe Base64	`-` `_`	`=` (often dropped)	None	RFC 4648 §5
MIME Base64	`+` `/`	`=`	76 chars, CRLF	RFC 2045
IMAP UTF-7	`+` `,`	None	None	RFC 3501
PEM / Base64	`+` `/`	`=`	64 chars, LF	RFC 7468

Why the `+`/`/` problem matters for URLs

The characters +, / and = all have reserved meanings in URLs. + means space in form-encoded data, / is a path separator, and = separates key from value in query strings. A standard Base64 string placed inside a URL query parameter without encoding will silently break. The URL-safe variant (- and _ instead, no padding) was designed exactly to eliminate this class of bug. JWTs, OAuth tokens, and web-safe file names should always use URL-safe Base64 or Base64url.

IMAP modified Base64 — the odd one out

RFC 3501 (IMAP) mailbox names are encoded with a Base64 variant that replaces / with , and omits padding, surrounded by &…- delimiters. Only the non-ASCII parts of a mailbox name are encoded; ASCII parts pass through unchanged. For example a Japanese folder name becomes a mix of ASCII and &<modified-base64>- segments. This variant is specific to IMAP and rarely encountered outside that protocol.

Worked example showing alphabet differences

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

input        Gera>?
standard     R2VyYT4/
url-safe     R2VyYT4_

The >? bytes produce symbols at positions 62 and 63, so the last two characters change between variants. All other characters in the output are identical.

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 to compare every variant on your own input.