What Base64 actually does
Base64 turns arbitrary binary data into a string built from just 64 printable ASCII characters: A-Z, a-z, 0-9, +, and / (with = used for padding). It exists because a lot of transport layers — email (MIME), URLs, JSON, XML, HTTP headers — were designed around printable text and either mangle raw bytes or forbid them outright. Base64 is the adapter that lets binary data pass through those pipes safely.
It is not encryption. Anyone can decode Base64 in one line of code with no key. If you see credentials "protected" by Base64, they are not protected at all — they're just formatted.
The algorithm, step by step
Base64 works in 3-byte → 4-character chunks:
- Take 3 bytes of input (24 bits total).
- Split those 24 bits into four 6-bit groups.
- Map each 6-bit group (a value from 0–63) to a character in the Base64 alphabet.
- If the input isn't a multiple of 3 bytes, pad the output with
=so the final group still has 4 characters.
Input: 'M' 'a' 'n'
Binary: 01001101 01100001 01101110
Regroup: 010011 010110 000101 101110
Decimal: 19 22 5 46
Base64: T W F u
Output: "TWFu"
This 3:4 ratio is why Base64 output is always ~33% larger than the original binary — a real cost if you're embedding large files or images (see Base64 for images).
Standard vs. URL-safe alphabets
There are two common variants:
| Variant | Characters 62/63 | Padding | Used for |
|---|---|---|---|
| Standard (RFC 4648 §4) | + / |
= |
Email attachments, generic binary-in-text |
| URL-safe (RFC 4648 §5) | - _ |
Often omitted | URLs, JWTs, filenames |
The difference matters because + and / have special meaning in URLs (+ can mean a space, / is a path separator) and in filenames on some systems. JWTs specifically use Base64URL without padding — decoding a JWT with a standard Base64 library that expects +// will silently produce garbage if the token happens to contain - or _.
Where Base64 shows up in practice
- Data URIs:
data:image/png;base64,iVBORw0KG...embeds an image directly in HTML/CSS, avoiding an extra HTTP request at the cost of the 33% size penalty and no separate browser caching. - JWTs: header and payload are JSON, Base64URL-encoded, joined with dots.
- Basic Auth: the
Authorization: Basic <base64(user:pass)>header — again, encoding, not encryption, so Basic Auth is only safe over HTTPS. - Embedding binary in JSON: JSON has no binary type, so file bytes, encryption keys, or protobuf payloads are often Base64-encoded into a string field.
Common mistakes
- Assuming it's secure. It isn't. Use actual encryption (AES, etc.) if confidentiality matters, and Base64-encode the ciphertext afterward if you need it in a text field.
- Forgetting padding rules when decoding by hand. A string missing its
=padding will fail strict decoders even though the data is valid — this is the single most common Base64 bug report. - Double-encoding. Running Base64 encode twice (often by accident in a pipeline) produces valid-looking but wrong output; the tell is an output string made up almost entirely of Base64-alphabet characters representing another Base64 string.
- Using standard Base64 where URL-safe is required, breaking links or tokens that contain
+or/.
FAQ
Does Base64 add security?
No — it's reversible by anyone with no key. It changes representation, not confidentiality.
Why does my encoded string end in one or two = signs?
Padding fills out the final 4-character group when the input length isn't a multiple of 3 bytes. One = means the last group encoded 2 leftover bytes; two = means 1 leftover byte.
Is Base64 encoding lossy?
No, it's fully reversible — decoding always reproduces the exact original bytes.
Why is my Base64 string a third longer than the original file?
Because 3 bytes of input become 4 characters of output — a fixed 4:3 expansion ratio, regardless of content.
Try it directly with the Base64 Encoder/Decoder — everything runs in your browser, so files never leave your device.