Base64 Encoder & Decoder

Base64 is a way of writing arbitrary binary data using only 64 printable characters: A–Z, a–z, 0–9, and two more — + and / in the standard alphabet. It exists because a great deal of software was built to carry text and behaves badly, or refuses outright, when handed raw bytes.

Email is the original example. SMTP was specified for 7-bit ASCII, so a mail server was free to mangle anything else. Base64 solves that by re-spelling the bytes of an attachment using characters every system already agrees on. The same reasoning applies wherever bytes have to survive a text-shaped channel: a JSON field, an HTTP header, a URL, a CSS file.

1Many hands make light work.

1TWFueSBoYW5kcyBtYWtlIGxpZ2h0IHdvcmsu

Nothing has been hidden and nothing has been lost — the second line is the first one, written in a smaller alphabet. That is worth holding onto, because it is the source of the single most common misunderstanding about Base64, which the section below on encryption returns to.

The mechanism is arithmetic, not magic. A byte holds 8 bits and there are 256 of them; a Base64 character holds 6 bits and there are 64. The lowest common multiple of 8 and 6 is 24, so the conversion works in 24-bit blocks — three bytes in, four characters out.

Read the table downwards. The three characters Man are the bytes 77, 97 and 110. Written as bits and joined together they make 24 bits. Those 24 bits are re-cut into four groups of six, each group is a number from 0 to 63, and each number picks a character from the alphabet. Man becomes TWFu.

Two details follow from this. First, the size: four characters for every three bytes is a 33% increase, which is why encoded output is always noticeably larger. Second, padding. Not every input divides neatly into three, so when one or two bytes are left over the final group is completed with = characters — one if two bytes remained, two if one did.

1"Man"   →   TWFu

1"Ma"    →   TWE=

1"M"     →   TQ==

There is one more step that trips implementations up, and it happens before any of this. Base64 encodes bytes, but text is not bytes until you choose an encoding. This tool converts text to UTF-8 first, which is why caféencodes as five bytes rather than four, and why emoji work at all. Tools built on the browser’s older btoa function skip that step and simply throw on anything outside Latin-1.

The two directions are exact inverses, and either can be run on any input — which makes it easy to reach for the wrong one.

Encoding takes bytes and produces Base64. It never fails: every possible sequence of bytes has an encoding. If the result looks wrong, the question is what went in, not what the encoder did.

Decoding takes Base64 and produces bytes, and it can fail, because not every string is valid Base64. Three things go wrong in practice:

• A character outside the alphabet. Almost always a value that was truncated, url-encoded on the way, or copied along with the text around it.
• Padding in the wrong place. Usually two separate values that have been concatenated — decode them one at a time.
• An impossible length. Base64 can never have exactly one character left over after groups of four, so that means characters are missing from the end.

There is a fourth outcome that is not a failure at all: the Base64 is perfectly valid, but the bytes it produces are not text. That is what happens when you decode an image or a PDF. This tool says so explicitly and lets you download the bytes, rather than showing you a screenful of replacement characters and calling it an error.

Because the two operations are inverses, the round trip is the quickest way to check yourself: encode, press Swap, and you should be looking at what you started with.

No. This is the most consequential misunderstanding about Base64, and it is worth being blunt: Base64 provides no security whatsoever.

Encryption depends on a secret. Without the key, ciphertext is unreadable — that is the whole point. Base64 has no key. The alphabet is published in an RFC, the algorithm is a page long, and every language ships a decoder. Anyone who can see the encoded value can read the original, and this page will do it for them in the time it takes to paste.

The confusion is understandable, because encoded text looks scrambled. But looking scrambled is not a security property. Three operations get mixed up here, and they do genuinely different jobs:

• Encoding — reversible by anyone, no key. Its job is compatibility: getting data through a channel intact. Base64, URL percent-encoding and UTF-8 are all encodings.
• Hashing — not reversible at all. Its job is integrity and identification: the SHA-256 of a file tells you whether the file changed, and cannot give you the file back.
• Encryption — reversible only with a key. Its job is confidentiality. AES and RSA are encryption; Base64 is not.

Two everyday consequences. HTTP Basic authentication sends your credentials as Base64, which is why it is only acceptable over HTTPS — the encoding protects nothing, the transport does. And a JWT’s payload is Base64, not encrypted: anyone holding the token can read every claim in it, which is all a JWT decoder does. The signature proves the token has not been altered; it does not make it private. Never put anything in a JWT payload that the bearer should not see.

The rule is simple. Treat Base64 exactly as you would treat the original data. If it needs protecting, encrypt it — and then, if you like, Base64 the ciphertext so it survives the journey.

What it is good at

• Universality. The alphabet is safe in almost every text context, and every platform has an implementation. Nothing has to be negotiated.
• Exactness. Encoding and decoding are lossless. The bytes that come out are the bytes that went in, every time.
• Simplicity. No configuration, no state, no failure modes worth speaking of on the encoding side.
• Predictable size. The output length is a formula, not a guess, which makes it easy to budget for.

What it is not good at

• It is not security. Worth repeating, because it is the mistake with actual consequences.
• It costs a third more space. Every time, in transfer, in storage and in memory. On a large payload that is a real bill.
• It resists compression. Encoded output has less redundancy than the bytes behind it, so compressing afterwards works poorly. Compress first, then encode.
• It defeats caching when inlined. An image embedded in a page as a data URI cannot be cached separately from that page, and is re-downloaded every time the page changes.
• It is unreadable to people. An encoded config value gives a reviewer nothing to review. Encode at the boundary where it is needed, not throughout.

A reasonable default: use Base64 where a text-only channel forces your hand, keep the encoded form as close to that boundary as you can, and prefer a plain file reference to an inlined one whenever the asset is big enough for the difference to matter.