What is Base64? Encoding Explained
Guide · Updated
Base64 is a binary-to-text encoding scheme that converts binary data into ASCII-compatible text using 64 printable characters. It is an encoding, not encryption—anyone can decode Base64 data without a key, so it must never be used to protect secrets. Base64 converts every 3 input bytes into 4 output characters, resulting in approximately 33% larger output.
What Base64 Is (and Isn't)
Base64 is a standardized encoding scheme defined in RFC 4648 that transforms binary data into a text format safe for transmission through systems designed for ASCII only. It uses 64 characters: A–Z, a–z, 0–9, plus (+), and forward slash (/), with an equals sign (=) for padding. Encoding is deterministic and reversible—the same input always produces the same output, and anyone can decode it.
The most critical misconception is that Base64 provides security. It does not. Base64 is encoding, not encryption. There is no key, no secret, and no mathematical barrier to reversal. A Base64-encoded password looks obfuscated, but decoding it takes one second and no credentials. If you need to protect data, use encryption (AES, RSA) or password hashing (bcrypt, Argon2). Base64 is for compatibility, not confidentiality.
How Base64 Works: The Math
Base64 encodes data by treating 3 input bytes (24 bits) as a single unit and splitting them into four 6-bit groups. Each 6-bit group maps to one of 64 characters in the Base64 alphabet. This is why 3 bytes become 4 characters: 3 bytes Ă— 8 bits = 24 bits; 24 bits Ă· 6 bits per character = 4 characters.
If input length is not a multiple of 3, Base64 adds padding with equals signs (=). One extra byte requires 8 bits → two 6-bit characters + two = signs. Two extra bytes → three characters + one = sign. This padding ensures output is always a multiple of 4 characters.
Worked example: the word "cat" (3 ASCII bytes: C=67, A=65, T=84) encodes to "Y2F0". In binary: 01000011 01000001 01010100 → split into groups: 010000 110100 000101 010100 → map to Base64 alphabet indices 16, 52, 5, 20 → characters Y, 2, F, 0.
| Input text | Bytes (binary) | Base64 |
|---|---|---|
| M | 01001101 | TQ== |
| Ma | 01001101 01100001 | TWE= |
| Man | 01001101 01100001 01101110 | TWFu |
| Hi | 01001000 01101001 | SGk= |
Size Increase: Why Encoded Data Gets Bigger
Base64-encoded data is always roughly 33% larger than the original. The math is simple: 4 output characters ÷ 3 input bytes = 1.333, or 33.3% overhead. A 1 MB file becomes approximately 1.33 MB when Base64-encoded. This size penalty is the trade-off for compatibility—readable text that passes through legacy systems that reject binary data.
The 33% increase assumes no newlines in the output. Some formats (MIME email, PEM certificates) insert line breaks every 76 characters for readability, which adds a bit more overhead but doesn't change the fundamental ratio.
Where Base64 Is Actually Used
Base64 is ubiquitous in modern web systems: Data URIs embed images or small files directly in HTML/CSS using the format data:[MIME-type];base64,[encoded data], avoiding extra HTTP requests. Every email attachment travels as Base64-encoded MIME data. JWT (JSON Web Token) authentication uses Base64URL for token headers and payloads (though the payload is readable, not secret). HTTP Basic Authentication encodes username:password in Base64 for the Authorization header.
It's also used in configuration files to represent binary values in text format, in APIs to transfer binary data over JSON, and as the container format for PEM certificates and SSH keys. The pattern is always the same: some system requires text-only input, so binary data is encoded first.
The Critical Security Lesson
Many developers treat Base64 as a lightweight encryption, especially for API keys, secrets, or user data. This is dangerous. Base64-encoded data reveals its content to anyone with a decoder—tools are everywhere and instant. If you have a Base64-encoded password in your code, it is effectively plaintext.
For real security: use encryption libraries (OpenSSL, libsodium) for confidential data, use password hashing (bcrypt, Argon2) for user passwords, and use HTTPS + TLS for transport security. Base64 is for format compatibility, not protection. If you need to encode sensitive data for storage or transmission, encrypt it first, then optionally Base64-encode the ciphertext if the destination requires text.
Frequently asked questions
Is Base64 the same as encryption?
No. Base64 is encoding—it converts binary data to text format. Encryption scrambles data so only someone with a key can read it. Base64 requires no key and anyone can decode it in seconds. Never use Base64 to protect secrets.
Why does Base64 make files bigger?
Because every 3 input bytes expand to 4 output characters. The ratio 4/3 equals 1.333, a 33% increase. This is the price of compatibility—making binary data safe for text-only systems.
Can I decode Base64 without knowing the original format?
Yes. Base64 decoding is deterministic and reversible. If you have the Base64 string, you can always get back the original binary data. No key or special knowledge is needed.
Why is Base64 used in JWTs if it's not secure?
Base64 in JWTs serves format compatibility and standardization, not security. The JWT signature (the third part) is what provides security. The payload in Base64 is readable by anyone—never store passwords, API keys, or credit card numbers there.
Is Base64URL different from standard Base64?
Yes, slightly. Base64URL (defined in RFC 4648) replaces + with - and / with _ to make encoded strings safe for URLs and filenames. It's used in JWTs and modern web APIs. Decoding is the same concept; the alphabet is just different.
What should I use instead of Base64 for protecting data?
For confidentiality: use encryption (AES-256 with proper key management). For passwords: use password hashing (bcrypt, Argon2). For data integrity: use HMAC or digital signatures. For transport: use HTTPS/TLS. Base64 is for format, not security.
Try the tools
Sources & references
This guide is general information to help you understand the topic and use the tools — it is not professional (financial, medical, legal, or tax) advice. Verify anything important before relying on it. See our Disclaimer.