Base64 (RFC 4648) is a binary-to-text encoding that represents arbitrary bytes using 64 printable ASCII characters — A-Z, a-z, 0-9, +, / — plus = for padding. It’s the standard way to embed binary blobs in text-only formats: email attachments, JWTs, PEM certificates, data URLs.
Format
Input: "Hello, World!" (13 bytes)
Base64: SGVsbG8sIFdvcmxkIQ== (20 chars)Every 3 input bytes → 4 output characters. When the input length isn’t a multiple of 3, output is padded with =.
Base64 vs Base64URL
Regular Base64 uses + and /, which have reserved meanings in URLs. Base64URL (RFC 4648 §5) substitutes:
+→-/→_=padding usually dropped
That’s why JWTs use Base64URL, not classic Base64.
Size Overhead
Base64 output is 33% larger than the input (4 output bytes per 3 input bytes). This is why HTTP/JSON APIs sending binary data over Base64 are heavier than protocols that use raw binary framing.
Common Miss
- Base64 is not encryption. It’s a bijective encoding — anyone can decode it. Storing “encoded” secrets in Base64 is the same as storing them in plaintext.
- Base64 is not compression. It makes data larger, not smaller.
- Using regular Base64 in URLs — the
/and+break things silently.
Encode and decode Base64, Base64URL, and hex with the Base64 converter.
Related
Check the JWT glossary entry, the UUID entry, and read the Base64 vs Base64URL FAQ.