How to use it
Paste your text into the input and press Encode. Going the other way, paste Base64 and press Decode.
Copy the result with one click. There is a file mode too, for encoding a file rather than typed text.
Base64 makes everything 33% bigger
This is the property that matters most in practice, and it explains a lot of odd behaviour elsewhere.
Base64 takes 3 bytes of input and represents them as 4 characters of output.
Four divided by three is 1.333, so encoded data always runs about a third larger than what went in. A 300 KB image becomes roughly 400 KB of Base64.
That overhead is unavoidable. It is what expressing arbitrary bytes in only 64 safe characters costs you, and it is why nobody uses Base64 where raw bytes would work instead.
You meet it constantly in two places.
Email attachments. Mail cannot carry raw binary, so every attachment gets Base64 encoded in transit. Your provider’s size limit applies to that encoded message rather than to the file on your desk, which is why a 25 MB cap really accepts a file of about 18 MB. The body text, the headers and any other attachments all come out of the same budget too, so the usable figure is lower still. This is the single most common reason a file that looks comfortably under the limit bounces back, and the error message almost never explains it.
Images embedded in CSS or HTML. A data URI inlines the image as Base64, saving an HTTP request at the cost of a third more bytes. Worse, those bytes can no longer be cached separately from the file they live inside, so a browser that already holds your stylesheet re-downloads every embedded image along with it whenever the CSS changes by a single character. For a 200-byte icon that trade is fine and often a genuine win. For a photograph it is close to indefensible, and it is a common reason a stylesheet that should be 40 KB arrives at half a megabyte.
The padding characters
Base64 output often ends in one or two = signs. They are padding, not data.
Encoding works in blocks of 3 bytes, so input that does not divide evenly leaves a partial block at the end. The = pads the output up to a multiple of 4 characters, telling a decoder where the real data stopped.
One = means your input was 2 bytes short of a full block. Two means 1 byte short.
You never see three, because that case needs no padding at all.
Some decoders accept unpadded input, others reject it outright. If a string refuses to decode and ends without padding, add = until the length divides by 4.
URL-safe Base64 is a different alphabet
Standard Base64 uses + and / among its 64 characters. Both already mean something in a URL. A plus sign reads as a space in query strings, and a slash separates path segments, so an encoded value dropped straight into a link can quietly come apart at either character.
Hence a second variant. base64url, defined in RFC 4648, swaps + for - and / for _ and leaves everything else alone. Padding usually gets dropped too, since = needs escaping in URLs as well.
JWTs use base64url for precisely this reason.
Pasted a token into a standard decoder and got nonsense? That alphabet mismatch is why. Converting between the two is a straight character swap, and nothing about the underlying data changes.
It is encoding, not encryption
Worth saying plainly, because the confusion is common and sometimes costly.
Base64 gives you no secrecy at all. There is no key. Anyone holding the string can decode it in one step, and the format is distinctive enough that automated scanners pick it out of a repository instantly.
Its real job is safe transport. Getting arbitrary bytes through a channel that only handles text, without anything being mangled on the way. That is a genuine problem worth solving, and it has nothing to do with security.
So credentials Base64-encoded in a config file are stored in plain text with an extra step. HTTP Basic Auth works exactly this way, which is precisely why it needs HTTPS underneath it.
Frequently asked questions
Is Base64 safe for secrets?
No. It is an encoding with no key, so anyone holding the string can decode it in one step.
Does it handle emoji and accents?
Yes, because text is treated as UTF-8 throughout, so emoji and accented characters make the round trip without damage.
Why does my encoded data end in equals signs?
Padding. It brings the output length up to a multiple of 4 so a decoder knows where your real data stopped. One = means the input was 2 bytes short of a full 3-byte block, and two means it was 1 byte short. Three never appears, because that case needs no padding at all.
Why will my JWT not decode as Base64?
JWTs use base64url, a variant that swaps + for - and / for _.
Why is my encoded file bigger than the original?
Because Base64 always is, by roughly a third. Three bytes go in and four characters come out, so the ratio holds no matter what you feed it.
Can I encode a file rather than text?
Yes, in file mode.
Related: encode an image as a data URI · decode a JWT · URL encode and decode · hash a value.