The Complete Technical Guide to Base64 Encoding and Decoding (RFC 4648)
Base64 is a binary-to-text encoding standard specified under IETF RFC 4648 designed to represent arbitrary binary data in an ASCII string format. Modern computer networks, protocols, and file formats—including email transfers (SMTP/MIME), HTTP headers, HTML Data URIs, and JSON Web Tokens (JWT)—frequently encounter channels designed strictly for 7-bit ASCII characters. Base64 bridges this architectural gap by converting raw bytes into a safe alphabet of 64 printable characters.
Every 3 bytes of raw binary data (24 bits) produce exactly 4 Base64 ASCII characters, resulting in a consistent 33.3% size overhead.
Replaces + and / with - and _ to prevent parameter conflicts in URLs, web endpoints, and cryptographic JWTs.
Embeds images, fonts, and documents directly into HTML <img> tags or CSS stylesheets via data:[mime];base64,[data].
How the Base64 Mathematical Algorithm Works
To understand Base64 encoding, consider the conversion of binary bits into characters:
- The encoder takes 3 consecutive 8-bit bytes (totaling 24 bits: 3 × 8 = 24).
- These 24 bits are split into 4 separate 6-bit groups (24 ÷ 6 = 4).
- Each 6-bit group represents a number from 0 to 63 (since 26 = 64).
- Each number is looked up in the RFC 4648 Base64 Index Table to yield an ASCII character.
- If the input length is not divisible by 3, one or two padding characters (
=) are appended to complete the 4-character block.
Encoding Step-by-Step Example: "Cat"
| Input Text | Char 1 ('C') | Char 2 ('a') | Char 3 ('t') |
|---|---|---|---|
| ASCII Value | 67 | 97 | 116 |
| 8-Bit Binary | 01000011 | 01100001 | 01110100 |
| 24-Bit Stream | 010000110110000101110100 | ||
| Re-grouped into 6-Bit Chunks | 010000 (Index 16 = 'Q') | 110110 (Index 54 = '2') | 000101 (Index 5 = 'F') 110100 (Index 52 = '0') |
| Base64 Encoded Result | Q2F0 | ||
The RFC 4648 Alphabet Reference Table
| Index Range | Characters | Binary Value | Usage |
|---|---|---|---|
| 0 – 25 | A – Z | 000000 – 011001 | Uppercase Latin alphabet |
| 26 – 51 | a – z | 011010 – 110011 | Lowercase Latin alphabet |
| 52 – 61 | 0 – 9 | 110100 – 111101 | Decimal digits |
| 62 | + (Standard) / - (URL-Safe) | 111110 | Symbol 62 |
| 63 | / (Standard) / _ (URL-Safe) | 111111 | Symbol 63 |
| Padding | = | Special | Aligns 4-character boundaries |
Standard Base64 vs. URL-Safe Base64 (base64url)
In standard Base64, the symbols + and / are valid characters. However, when sending data over HTTP GET requests, URLs, or cookies:
- Web servers interpret
+as an encoded space character, corrupting the payload. - The
/character denotes URI path separators, breaking URL routing.
RFC 4648 Section 5 created base64url by replacing + with - (hyphen) and / with _ (underscore), while optionally omitting the trailing = padding. This variant is mandatory for JSON Web Tokens (JWT) and web safe API tokens.
Line Wrapping: MIME (76 Chars) vs. PEM (64 Chars)
Standard protocols enforce maximum line lengths to avoid buffer overflow in legacy email and security systems:
- MIME Email Standard (RFC 2045): Requires Base64 lines to be wrapped at a maximum of 76 characters, terminated with CRLF line breaks.
- PEM Security Certificates (RFC 7468): Cryptographic keys (RSA, ECDSA), SSL certificates, and SSH keys format raw DER bytes into 64-character lines surrounded by headers such as
-----BEGIN CERTIFICATE-----.
Frequently Asked Questions (FAQ)
<img src="data:image/png;base64,iVBOR..." alt="Embedded Image">. This eliminates the need for a separate image file on your server.
TextEncoder and TextDecoder APIs, ensuring 100% accurate multi-byte UTF-8 handling for Arabic, Urdu, Chinese, Japanese, accented letters, and Emojis.