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.