Base64 encoder and decoder

Base64 encodes bytes, not characters. Text has to become bytes first, and the rule for doing that is the character encoding. Almost everything today uses UTF-8, where an ASCII letter is one byte, an accented letter is two, a CJK character is three and an emoji is four.

The browser btoa function ignores all of that and assumes one byte per character. Hand it an emoji and it throws an error. Hand it an accented letter and it does something worse: it silently encodes the Latin-1 byte, so cafe with an accent encodes to Y2Fm6Q== instead of Y2Fmw6k=, and decoding that anywhere expecting UTF-8 produces a replacement character. This tool runs the text through TextEncoder first and TextDecoder on the way back, so what goes in is what comes out.

Decoding is strict on purpose. If the bytes are not valid UTF-8, you are told so rather than being handed a string full of replacement characters, because that usually means the data is a file rather than text.

Standard base64 uses 64 characters: A to Z, a to z, 0 to 9, plus and slash, with equals signs padding the end. Plus and slash both mean something inside a URL, so pasting standard base64 into one mangles it.

The URL safe variant swaps them for dash and underscore and usually drops the padding. JSON web tokens use it, which is why a JWT payload decodes here and fails in a stricter decoder. This decoder accepts either alphabet, restores missing padding, and ignores the line breaks that base64 in email headers and PEM certificates always carries.

It exists to move binary data through channels that only accept text: email attachments, data URIs in CSS, JSON payloads, certificates. The cost is size. Three bytes become four characters, so the encoded form is about a third larger, which is why inlining a large image as a data URI is usually a mistake.

It is not encryption. There is no key and nothing secret about it. Anyone can paste it into a page like this one and read it back, so base64 hides nothing, and a token or a password is exactly as exposed after encoding as before.

Is my text or file uploaded when I encode it?

No. Encoding and decoding both happen in your browser, and a file you choose is read from disk into memory in this tab rather than sent anywhere. Nothing is uploaded, logged or stored.

Why do accented characters and emoji break in other base64 tools?

Because base64 encodes bytes, not characters, and the browser btoa function assumes one byte per character. Emoji make it throw an error outright. Accented letters are worse: btoa quietly encodes the Latin-1 byte, so cafe with an accent comes back as mojibake instead of failing. This tool converts to UTF-8 bytes with TextEncoder first, so both survive exactly.

What is URL safe base64?

Standard base64 uses plus and slash, which both have a meaning inside a URL and get percent-encoded when you paste them into one. The URL safe variant swaps them for dash and underscore, and usually drops the trailing equals signs. JSON web tokens use it, which is why a JWT decodes here and not in a strict decoder.

Why did my base64 get about a third bigger?

Base64 stores three bytes in four characters, so the encoded form is always around 33 percent larger than the original plus a little padding. That is the cost of moving binary data through something that only accepts text, and it is the reason not to base64 large images into your HTML.

Do I need the equals signs at the end?

They pad the data out to a whole number of four character groups. Some systems require them and others strip them, so this decoder restores them for you if they are missing. It also ignores line breaks, which base64 in email headers and PEM certificates always has.

Is base64 a form of encryption?

No, and this is worth being blunt about. It is an encoding, fully reversible by anyone, with no key involved. Anything you base64 is as readable as the original to anyone who pastes it into a decoder like this one, so it hides nothing.