What Base64 is (and what it is not)
Base64 turns any sequence of bytes into plain text built from 64 safe characters: A-Z, a-z, 0-9, plus + and /. It exists because many protocols — email, JSON, URLs, HTML attributes — carry only text, and raw binary data gets mangled along the way. Encoding groups every 3 input bytes into 4 output characters, which is why the result is always about 33 % larger than the original.
One thing Base64 is not: encryption. There is no key — anyone can reverse it instantly, including this page. Treat anything Base64-encoded as fully readable.
Where you will run into it as a developer:
- Data URIs: inlining small icons in CSS or HTML via
data:image/svg+xml;base64,.... - JWTs: the header and payload of a JSON Web Token are Base64URL blocks you can decode and inspect right here.
- Email attachments: MIME has encoded attachments this way for decades.
- HTTP Basic auth, API payloads, config secrets: any place bytes must ride inside text.
How to use this tool
- Pick the Encode tab (text → Base64) or the Decode tab (Base64 → text).
- Type or paste your content — the output updates as you type, no convert button.
- Hit Copy to grab the result.
- If the input on the decode side is not valid Base64, you get a clear “Invalid Base64” message instead of garbage.
Everything runs locally in your browser; nothing is uploaded anywhere.
The method, step by step
The encoder reads input bytes 3 at a time (24 bits), splits them into four 6-bit values, and maps each value to one character of the 64-symbol alphabet. When the final group is short, it pads the output with = signs.
Worked example
Let’s encode the word Hello — 5 bytes in UTF-8: 72, 101, 108, 108, 111.
- The first 3 bytes (72, 101, 108) form 24 bits. Split into 6-bit values they give 18, 6, 21 and 44, which map to S, G, V and s.
- The remaining 2 bytes (108, 111) give 16 bits, padded with zeros into the values 27, 6 and 60 — that’s b, G and 8 — plus one = of padding.
Result: SGVsbG8=. Five bytes became 8 characters, matching the ceil(5 ÷ 3) × 4 rule.
How much bigger does the output get?
| Input size (bytes) | Base64 output (characters) |
|---|---|
| 1 | 4 |
| 3 | 4 |
| 5 | 8 |
| 10 | 16 |
| 100 | 136 |
| 1,000 | 1,336 |
| 10,000 | 13,336 |
| 1,048,576 (1 MB) | 1,398,104 (≈1.33 MB) |
The formula: output length = 4 × ceil(bytes ÷ 3). That overhead is why inlining large images as data URIs is usually a bad trade.
The UTF-8 gotcha with btoa
The browser’s built-in btoa only accepts latin1 characters (codes 0 through 255). Feed it an emoji or accented text and it throws an exception. The correct approach — used by this tool — is to convert the string to UTF-8 bytes with TextEncoder first, then encode those bytes; decoding reverses the trip through TextDecoder. That’s how 😀 encodes cleanly to 8J+YgA== (the emoji is 4 bytes in UTF-8), while a naive btoa call simply crashes.
Frequently asked questions
Is Base64 safe for passwords or secrets?
No. It is an encoding, not encryption — decoding requires no key and takes milliseconds. A password stored “in Base64” is effectively stored in plain text. Use real cryptography (and salted hashing for passwords) when secrecy matters.
What do the = signs at the end mean?
They are padding. Output is produced in blocks of 4 characters; when the input length is not a multiple of 3 bytes, one = marks a missing byte and == marks two. Some encoders strip the padding, and most decoders accept the string either way.
What is the difference between Base64 and Base64URL?
Base64URL swaps + for - and / for _ so the result can live inside URLs and filenames without escaping, and it usually drops the = padding. JWTs use Base64URL — if a token segment fails to decode here, replace those two characters and try again.
Why does my decoded output look like gibberish?
Valid Base64 does not guarantee the underlying bytes are text. If someone encoded an image, a ZIP or random bytes, decoding to text produces replacement characters. Decoding only makes sense when the original content was UTF-8 text.