What is Base64?
Base64 is a way to represent arbitrary bytes using only 64 safe,
printable characters: the letters A–Z and a–z, the digits 0–9, and two
symbols (+ and /), with = used
as padding. It was designed for a world of text-only pipes — email
systems, early web protocols, configuration formats — that would mangle
or reject raw binary data. Encode a file, an image or an encrypted blob
as Base64 and it becomes ordinary text that any of those systems can
carry undamaged; decode it at the other end and the original bytes come
back, bit for bit.
That is all Base64 is: a transport encoding. It provides no secrecy, no compression and no integrity checking — anyone can decode it (you just did, above), and the output is about a third larger than the input. Its ubiquity comes from how many places need "binary, but as text": email attachments (MIME), images embedded in HTML and CSS as data URIs, JSON Web Tokens, HTTP Basic authentication, XML documents, and API payloads of every description.
How to use this tool
- To encode: type or paste text into the top field and press Encode →. The Base64 appears in the lower field.
- To decode: paste Base64 into the lower field and press ← Decode. The recovered text appears above. Invalid input is rejected with an explanation rather than partial garbage.
- Tick URL-safe when the result will live in a URL, a filename or a JWT — the output then uses
-and_instead of+and/, and drops the=padding. - Text is handled as UTF-8, so text in any language — and emoji — encodes and decodes correctly.
How Base64 works
The encoder reads the input three bytes at a time. Three bytes are
24 bits, and 24 divides neatly into four groups of 6 bits. Each 6-bit
group is a number from 0 to 63, which indexes the 64-character
alphabet: 0–25 are A–Z, 26–51 are a–z, 52–61 are 0–9, and 62 and 63 are
+ and /. Four output characters therefore
carry exactly three input bytes — which is also where the 33% size
increase comes from.
If the input does not divide into 3, the last group is short: one
leftover byte produces two characters plus ==; two leftover
bytes produce three characters plus =. The padding lets a
decoder know exactly how many bytes the final group represents.
Decoding runs the same machinery in reverse — characters back to 6-bit
groups, groups back to bytes — and any character outside the alphabet
is an error worth reporting, not something to silently skip. (Some
lenient decoders ignore stray characters; this one accepts harmless
whitespace from line wrapping, and rejects anything else.)
Examples
| Text | Base64 |
|---|---|
| hello | aGVsbG8= |
| hello world | aGVsbG8gd29ybGQ= |
| {"a":1} | eyJhIjoxfQ== |
| ✓ | 4pyT |
Short inputs are worth studying: hello and
aGVsbG8= are the same five bytes in two alphabets, and the
shared aGVsbG8 prefix of the first two rows shows how
encoding is purely mechanical — same bytes in, same characters out.
Common mistakes
- Treating Base64 as security. Credentials "protected" by Base64 (as in HTTP Basic auth) are public to anyone who sees them. It is encoding, not encryption.
- Double-encoding. Encoding an already-encoded string produces valid-looking output that decodes to the encoded text, not the original — a classic debugging time sink.
- Breaking long strings. Email-style line wrapping is fine for this decoder, but deleting characters mid-string is not: one missing character corrupts everything after it.
- Forgetting the alphabet variant. Standard Base64 in a URL query string can be mangled by
+being read as a space. Use the URL-safe variant there, and in JWTs (which use Base64URL for every segment). - Assuming text. Decoded bytes that are not valid UTF-8 are probably binary data — save them as a file rather than expecting readable text.
For the full history and design rationale, read Base64 encoding explained.