The Problem Base64 Solves
Base64 represents binary bytes using a text-safe alphabet, which is useful when a system expects text rather than arbitrary binary data. A JPEG, for example, consists of bytes for image data and metadata that cannot always be passed safely through text-oriented formats unchanged.
Many systems were designed to handle text reliably, but not arbitrary binary data. The classic example is email. The original email protocol (SMTP) was designed in the early 1980s for plain ASCII text. When someone tried to attach a binary file - say, an image or a spreadsheet - the email servers would sometimes mangle the data. Certain byte values had special meaning to the protocol (like the byte for a newline character), and running into them in the middle of a binary file corrupted the attachment.
The solution: convert binary data into a subset of printable text characters that every system agrees is safe to transmit. That's exactly what Base64 does. It takes any binary data and represents it using only 64 characters that are universally safe across protocols.
The Base64 Alphabet
Base64 uses exactly 64 characters:
- A-Z - 26 uppercase letters
- a-z - 26 lowercase letters
- 0-9 - 10 digits
- + and / - 2 special characters
That's 64 characters total. Since 2⁶ = 64, each Base64 character can represent exactly 6 bits of binary data. You'll also see the = (equals sign) used as a padding character, but it's not part of the core alphabet - it just signals the end of the encoded data.
Why 64 specifically? It's the largest power of 2 that fits within the printable, universally compatible ASCII characters. Using all 128 ASCII characters would be simpler mathematically, but many of them (control characters, characters above 127) aren't safe for text-based protocols.
How Base64 Encoding Works Step by Step
Let's walk through encoding the word "Man" to see the algorithm in action:
Step 1: Convert Characters to Binary
Each ASCII character is 8 bits. "Man" in ASCII is:
- M = 77 decimal =
01001101
- a = 97 decimal =
01100001
- n = 110 decimal =
01101110
Combined: 010011010110000101101110 - 24 bits total
Step 2: Split Into 6-Bit Groups
Divide the 24-bit string into groups of 6:
010011 = 19
010110 = 22
000101 = 5
101110 = 46
Step 3: Look Up Each Value in the Base64 Alphabet
- 19 → T
- 22 → W
- 5 → F
- 46 → u
Result: TWFu
You can verify this yourself - the word "Man" always encodes to "TWFu" in Base64. The algorithm is completely deterministic.
The Padding Rule
Base64 always works in groups of 3 input bytes (24 bits), producing 4 output characters. When the input isn't divisible by 3, padding characters (=) fill the gap:
- 1 remaining byte → 2 Base64 chars +
==
- 2 remaining bytes → 3 Base64 chars +
=
- 3 remaining bytes → 4 Base64 chars (no padding needed)
💡 Tip: If you see a string ending in
= or
==, there's a good chance it's Base64-encoded data. You can decode it instantly using the
Kinsad Base64 Encoder/Decoder.
Real-World Use Cases for Base64
1. Email Attachments (MIME)
When you attach a file to an email, your email client encodes it as Base64 and embeds it in the email body as text. The recipient's client decodes it back to the original file. This is why email files can be so large - the 33% size overhead (more on that below) inflates every attachment.
2. Data URIs for Images
Instead of referencing an image file with a URL, web developers can embed images directly in HTML or CSS using a data URI:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg...">
This can be convenient for a small icon or an image that should travel with a document, but Base64 makes the data larger and embeds it in the page or stylesheet. For larger images, a separate image file is often easier to cache and maintain. The iVBORw0KGgo prefix is commonly seen at the start of Base64-encoded PNG data.
3. HTTP Basic Authentication
When a web server requires Basic Auth, credentials are sent as username:password encoded in Base64 in the HTTP header:
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
Decode that value and you get username:password in plain text. This is why Basic Auth over plain HTTP is unsafe - the "encoding" provides zero security.
4. JWT Tokens
JSON Web Tokens (JWTs) - used for authentication in most modern web apps - consist of three Base64URL-encoded parts separated by dots:
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyMTIzIn0.abc123...
The first part is the header, the second is the payload (your user ID and claims), and the third is the signature. The first two are Base64URL-encoded (not encrypted) - anyone can decode and read them. Only the signature is cryptographically verified.
5. Storing Binary Data in Text Fields
Databases and configuration files often store binary data as Base64 strings. TLS certificates, SSH keys, and API keys are commonly stored and transmitted in Base64-encoded form (you may recognize the -----BEGIN CERTIFICATE----- header - everything between those markers is Base64).
Base64 Is NOT Encryption
This is the most important thing to understand about Base64. Encoding is not encryption.
Encryption transforms data so that only someone with the correct key can read it. Base64 encoding is entirely reversible by anyone - there's no key, no secret, no protection. Anyone who sees a Base64 string can decode it instantly.
| Property |
Base64 Encoding |
Encryption (e.g., AES) |
| Purpose |
Format conversion for safe transmission |
Protecting data from unauthorized access |
| Requires a key? |
❌ No |
✅ Yes |
| Reversible by anyone? |
✅ Yes - trivially |
❌ No - only with the correct key |
| Provides security? |
❌ None whatsoever |
✅ Yes (when implemented correctly) |
| Output size change |
+33% larger |
Varies (often similar size) |
⚠️ Warning: Never use Base64 to "hide" sensitive information like passwords, API keys, or personal data in your applications. Base64 is transparent - it's just a different way to write the same data. Any developer who sees it can decode it in seconds.
The 33% Size Overhead
Because Base64 converts 3 bytes into 4 characters, every file encoded in Base64 becomes approximately 33% larger. A 1 MB image embedded as Base64 in your HTML will add roughly 1.33 MB to the page size.
For email attachments, this is unavoidable - the protocol requires it. For web development, you should only use data URIs for very small assets (icons under a few kilobytes) where eliminating the HTTP request is worth the size penalty.
Base64URL: The URL-Safe Variant
Standard Base64 uses + and / - both characters that have special meaning in URLs. If you include a Base64 string in a URL query parameter, these characters need to be percent-encoded, which makes the URL messy.
Base64URL solves this by replacing + with - and / with _. It also typically omits the padding = characters. You'll see Base64URL used in JWT tokens, OAuth codes, and any Base64 data that needs to live in a URL.
Frequently Asked Questions
Q: Can I decode any Base64 string?
Yes - anyone can decode any Base64 string without a key or password. That's the point: Base64 is a format transformation, not a security measure. Paste any Base64-encoded text into a decoder and you'll see the original data immediately.
Q: How do I know if a string is Base64-encoded?
Look for strings that contain only letters (uppercase and lowercase), numbers, +, /, and = signs. The string length is always a multiple of 4 (after accounting for padding). Strings ending in = or == are almost certainly Base64. However, not all strings matching this pattern are Base64 - some alphanumeric strings coincidentally look like valid Base64.
Q: Why does Base64 add 33% to the file size?
Base64 converts every 3 bytes (24 bits) of input into 4 characters of output (each character representing 6 bits). So 3 bytes become 4 bytes - a 33% increase. For every kilobyte of original data, you get roughly 1.33 kilobytes of Base64-encoded data.
Q: What's the difference between Base64 and Base64URL?
Base64URL is a variant designed for use in URLs and filenames. It replaces the + character with - and the / character with _, and typically omits padding = characters. The encoding algorithm is otherwise identical. JWT tokens use Base64URL for their header and payload sections.
Q: Is Base64 used for passwords?
Passwords should never be stored in Base64 - it provides zero security since anyone can decode it. Passwords should be hashed using a proper password hashing algorithm like bcrypt, scrypt, or Argon2. These are one-way functions that cannot be reversed, unlike Base64 which is trivially reversible.
Q: Why is it called Base64 and not something else?
The "64" refers to the number of characters in the encoding alphabet. Other similar schemes exist: Base32 uses 32 characters (A-Z plus 2-7), Base16 is hexadecimal (0-9 and A-F), and Base58 is used in Bitcoin addresses (avoids confusing characters like 0, O, I, and l). Base64 is the most common because it achieves good density while staying within universally safe ASCII characters.
Encode and Decode Base64 Instantly
Use Kinsad's free Base64 encoder/decoder to convert text or files to Base64 and back. Supports both standard Base64 and Base64URL variants, with no data stored on our servers.
Use the Base64 Encoder/Decoder →