You've probably seen strings like SGVsbG8sIFdvcmxkIQ== in a JWT token, an HTTP Authorization header, or embedded inside an HTML file as a tiny image. That's Base64 — one of those encoding schemes that turns up everywhere once you know what to look for. It's not encryption, it's not compression, and it has nothing to do with hexadecimal. It's a specific way to represent arbitrary binary data using only printable text characters, and understanding it takes about ten minutes.
- Base64 encodes binary data as text using a 64-character alphabet — letters, digits,
+, and/ - Every 3 bytes of input become 4 Base64 characters; output is always ~33% larger than input
- Base64 is not encryption — anyone can decode it instantly with any standard library
- It's used when binary data must pass through a channel that only handles text (HTTP headers, JSON, email)
- URL-safe Base64 replaces
+and/with-and_to avoid conflicts in URLs and filenames - Data URIs embed images or files directly in HTML/CSS using Base64, eliminating extra HTTP requests
Why Base64 Exists
Computers store everything — text, images, audio, executables — as binary data: streams of bytes with values from 0 to 255. Many older communication protocols were designed to carry only printable ASCII text (values 32–126). When you try to transmit raw binary through one of those text-only channels, certain byte values get misinterpreted, corrupted, or stripped entirely. Bytes 0–31 include control characters like newline, carriage return, and null — values that many protocols treat as special commands rather than data.
Base64 solves this by converting arbitrary binary into a representation that uses only 64 safe, printable characters: uppercase A–Z (26), lowercase a–z (26), digits 0–9 (10), plus sign +, and forward slash /. The result can safely travel through any text-based protocol without corruption. An equals sign = is used as padding at the end when the input length isn't a multiple of three bytes.
SMTP email was the original driver. Email systems were designed for ASCII text, so Base64 became the standard way to attach images, PDFs, and other binary files to email messages — which is why email attachments work at all across different mail servers. HTTP and JSON inherited the need for the same reason: they're text protocols, and passing raw binary through them without Base64 would break parsers and corrupt data.
How the Encoding Algorithm Works
The mechanics are straightforward. Take the input as bytes, group them into chunks of 3 bytes (24 bits), then split each 24-bit chunk into four 6-bit groups. Each 6-bit group maps to one of 64 characters in the Base64 alphabet. Since 2^6 = 64, six bits can represent exactly 64 possible values — hence the name.
Let's encode the word "Man" step by step.
The ASCII values are: M = 77, a = 97, n = 110. In binary:
M a n
01001101 01100001 01101110Group those 24 bits into four 6-bit chunks:
010011 010110 000101 101110
19 22 5 46Look up each value in the Base64 alphabet (A=0, B=1, … Z=25, a=26, … z=51, 0=52, … 9=61, +=62, /=63):
19 → T
22 → W
5 → F
46 → u"Man" encodes to TWFu. You can verify this with any Base64 tool or by running btoa("Man") in your browser's JavaScript console.
When the input isn't divisible by 3, padding comes into play. If there's 1 leftover byte, it gets padded to 2 Base64 characters followed by ==. If there are 2 leftover bytes, they produce 3 Base64 characters followed by one =. Padding ensures the output length is always a multiple of 4 characters.
The Size Overhead
Base64 encoding always increases the data size. Every 3 bytes of binary become 4 Base64 characters — a 4/3 ratio, or roughly a 33% size increase. A 100 KB image Base64-encoded into an HTML file becomes about 133 KB of text. For large files, this overhead is significant. A 5 MB PDF attachment becomes about 6.7 MB in a Base64-encoded email.
This size penalty is one of the primary trade-offs to consider when deciding whether Base64 is the right tool. For small assets — icons, tiny thumbnails, inline fonts under a few KB — the 33% overhead is usually acceptable and is outweighed by the benefits of eliminating an HTTP request. For anything larger, serving the binary directly is almost always the better choice.
Where You Actually Encounter Base64
Once you know what Base64 looks like, you'll notice it everywhere:
JWT tokens (JSON Web Tokens) — JWTs consist of three Base64url-encoded sections separated by dots: header, payload, and signature. The header and payload are just Base64-encoded JSON; the signature is a cryptographic hash. Because it's only Base64 encoding (not encryption), the header and payload are readable by anyone who decodes them. JWTs rely on the signature for integrity, not on the encoding for secrecy.
HTTP Basic Authentication — The Authorization header for Basic auth looks like Authorization: Basic dXNlcjpwYXNz. The value after "Basic " is the Base64 encoding of username:password. Again, this is not encryption — anyone who intercepts the header can decode it instantly. Basic Auth must always be used over HTTPS.
Data URIs in HTML/CSS — You can embed images directly in HTML without a separate file: <img src="data:image/png;base64,iVBORw0K...">. Browsers interpret this as an inline PNG. Useful for tiny icons in emails or CSS, where a separate HTTP request would add latency for a negligible payload.
Email attachments (MIME) — Every attachment in an email is Base64-encoded in the message body. When your email client "downloads" an attachment, it's decoding Base64 text back into the original binary file.
API responses containing binary data — REST APIs that return images, PDFs, or other binary blobs often encode them in Base64 within a JSON response, since JSON itself is a text format and cannot directly represent arbitrary bytes.
Environment variables and configuration — Secret keys and certificates stored in environment variables are commonly Base64-encoded to avoid issues with special characters, newlines, or shell interpretation.
URL-Safe Base64
Standard Base64 uses + and / characters, which have special meanings in URLs (+ means space in query strings; / delimits path segments). When Base64 data needs to appear in a URL or filename, these characters cause problems.
URL-safe Base64 (also called Base64url) replaces + with - and / with _, and typically omits the = padding. The result is safe to use directly in a URL query parameter or as a filename without percent-encoding. JWT tokens use Base64url for exactly this reason — they frequently appear in URLs and HTTP headers.
If you see a Base64-like string with hyphens and underscores instead of plus and slash signs, it's Base64url. Most Base64 libraries have a URL-safe mode or a separate function for it.
Base64 Is Not Encryption — Ever
This bears repeating loudly: Base64 encoding provides zero security. It is a reversible transformation. Any developer can decode a Base64 string in seconds with a single function call in any language. There is no key, no secret, no obfuscation that makes it harder to reverse. It is purely a text-safe representation of binary data.
Treating Base64-encoded data as "protected" is a classic and dangerous mistake. Passwords encoded in Base64 are fully exposed. Sensitive configuration values in Base64 are readable by anyone who sees them. "Obscurity" through Base64 is not a security measure — it's a false sense of safety. If data needs to be protected, use actual encryption (AES, ChaCha20) or hashing (bcrypt, Argon2 for passwords). Base64 is the wrong tool for that job entirely.
Encoding and Decoding in Common Languages
Every mainstream language has built-in Base64 support:
// JavaScript (browser)
btoa("Hello") // encode → "SGVsbG8="
atob("SGVsbG8=") // decode → "Hello"
// JavaScript (Node.js)
Buffer.from("Hello").toString("base64") // encode
Buffer.from("SGVsbG8=", "base64").toString() // decode
// Python
import base64
base64.b64encode(b"Hello") # encode → b'SGVsbG8='
base64.b64decode("SGVsbG8=") # decode → b'Hello'
// command line
echo -n "Hello" | base64 # encode
echo "SGVsbG8=" | base64 --decode # decodeFor URL-safe Base64 in Python, use base64.urlsafe_b64encode(). In Node.js, replace the standard output with a .replace(/\+/g, '-').replace(/\//g, '_') transformation, or use a dedicated library.
Try It Yourself
The QuickUtil Base64 Encoder/Decoder lets you encode or decode any text or data instantly in your browser — no installation needed. Useful for inspecting JWT payloads, debugging API responses, or converting small files for inline embedding. If you're working with URLs and need to encode query parameters or decode URL-encoded strings, the URL Encoder/Decoder handles percent-encoding in the same straightforward way.