BASE64
DECODER

Base64 is not encryption and never claimed to be. RFC 4648 exists because base encoding is used "to store or transfer data in environments that, perhaps for legacy reasons, are restricted to US-ASCII data." That's a plumbing problem, not a secrecy one.

If you've found a Base64 string and hoped it was hiding something, we've got bad news and it takes one paste into the box above to confirm it.

Key Takeaways

• RFC 4648, The Base16, Base32, and Base64 Data Encodings, was published in October 2006.
• Its stated motivation is channels "restricted to US-ASCII data", though the RFC notes new applications use it too.
• The alphabet is "a 65-character subset of US-ASCII", "enabling 6 bits to be represented per printable character".
• Padding uses =, and the spec requires it unless another standard says otherwise.
• The URL-safe variant swaps characters 62 and 63: + and / become - and _.

Why does Base64 exist at all?

Because plenty of systems were built to carry text and will damage anything that isn't. RFC 4648 puts it plainly: base encoding is used "to store or transfer data in environments that, perhaps for legacy reasons, are restricted to US-ASCII data" (RFC 4648).

Email is the obvious case, though it isn't the RFC's example. A mail system that assumes text can mangle a raw byte that happens to look like a control character, or a newline, or the end of a message. Base64 fixes that by expressing arbitrary bytes using only characters such systems agree are safe to pass along untouched.

The spec notes the other benefit too: it "makes it possible to manipulate objects with text editors". Pasting a certificate into a config file is our example of that, not the RFC's.

Why 64 characters, and why does it get bigger?

Because 64 is 2 to the sixth, so one printable character can carry exactly 6 bits. RFC 4648 describes it as "a 65-character subset of US-ASCII" and says the point is "enabling 6 bits to be represented per printable character."

The sixty-fifth character is the padding one, which is why the count is 65 rather than 64.

Here's the cost. A byte is 8 bits and a Base64 character carries 6, so three bytes become four characters: a 33% increase once your input divides neatly by three. Short inputs pay more, because the final group is padded out to four characters regardless. One byte still costs you four characters.

Input	Bits	Output characters
3 bytes	24	4
2 bytes	16	4 (with 1 pad)
1 byte	8	4 (with 2 pads)

What are the equals signs for?

They pad the last group out to four characters when your data doesn't divide neatly by three. RFC 4648 states that "padding at the end of the data is performed using the '=' character", and that implementations must include it unless a referencing specification says otherwise.

That's why the padding is a tell rather than a mystery. One = means the final group held two bytes. Two = means it held one. No = means your input length was already a multiple of three.

Truncation is a common cause of decode failure for that reason. Chop a Base64 string in half and the padding no longer describes the data, so a strict decoder refuses it rather than guessing: RFC 4648 requires implementations to reject characters outside the base alphabet.

What is the URL-safe variant?

The same encoding with two characters swapped, because + and / both mean something else in a URL.

The RFC calls it base64url. Its second table replaces alphabet characters 62 and 63: the plus sign becomes a hyphen and the forward slash an underscore, which the spec describes as making the encoding suitable for filenames and URLs. Everything else is identical, and Table 2 is normative rather than advisory.

This matters practically. Pick the wrong variant in the selector above and a string full of - and _ will decode to nonsense, because a standard decoder reads those as invalid rather than as 62 and 63.

So can Base64 hide anything?

No, and the reason is worth being precise about. Base64 has no key. There's nothing you know that a reader doesn't, so the transformation carries no secret and reverses in one step.

It's an encoding, which changes how data is represented. Encryption changes who can read it. Those are different jobs, and mistaking one for the other is how secrets end up sitting in plain sight.

If you want the version of this that does have a key, however weak, the Caesar cipher is the smallest possible example, and Atbash is what happens when you take even that away.

Frequently asked questions

Is Base64 encryption?

No. RFC 4648 defines an encoding, and gives channels restricted to US-ASCII as the reason one is wanted. It has no key, so anyone can reverse it instantly. It changes how data is represented, not who can read it.

What does the = at the end of a Base64 string mean?

Padding. RFC 4648 specifies = as the padding character, used to fill the final group out to four characters. One = means the last group held two bytes; two means it held one.

Why is Base64 longer than the original?

Because each character carries only 6 bits while a byte holds 8, so three bytes become four characters, about 33% larger. Inputs that don't divide by three pay more, since the last group is padded to four characters either way. That overhead buys the guarantee that text-only systems pass the data through unaltered.

What is the difference between standard and URL-safe Base64?

Two characters. RFC 4648's URL-safe table replaces characters 62 and 63, so + becomes - and / becomes _, which makes the output safe in filenames and URLs. The rest of the alphabet is unchanged.

Why did my Base64 decode fail?

Usually the string is truncated so the padding no longer matches the data, or it contains characters outside the chosen alphabet, or you picked the standard variant for a URL-safe string. A strict decoder refuses rather than guessing.

Paste a string into the box above and it'll tell you in one go. Or go and look at the ciphers that actually keep a secret.

Sources

• IETF, RFC 4648, The Base16, Base32, and Base64 Data Encodings, October 2006 - retrieved 30 July 2026, https://www.rfc-editor.org/rfc/rfc4648.txt