Base64 Encoder and Decoder
- 12
- Characters in
- 24
- Characters out
- +33%
- Size change
The encoder converts text to Base64, and the decoder converts it back. Both directions handle Unicode correctly, which is where most simple implementations fail, and the decoder accepts the URL-safe alphabet and missing padding rather than rejecting them.
How it works
Base64 represents binary data using 64 printable characters. Every three bytes become four characters, which is why encoded output is about a third larger than what went in. It is an encoding, not encryption. Anyone can reverse it, and it protects nothing.
- Text is converted to UTF-8 bytes before encoding. The browser's btoa function works on Latin-1 and throws on any character above 255, so encoding "café" without this step fails outright.
- The URL-safe variant replaces + with - and / with _ and drops the = padding, so the result can sit in a URL or filename unescaped.
- Decoding accepts either alphabet and restores missing padding, because a great many systems strip it.
- Wrapping at 76 characters is the MIME convention, still expected by some mail and certificate tooling.
A decoded length that is not a multiple of 4 after padding is restored (specifically, a remainder of 1) cannot be valid Base64 at all, and is reported as such rather than silently producing rubbish.
Examples
Text with an accent and an emoji
Text
Hello, café 👋
Result
SGVsbG8sIGNhZsOpIPCfkYs=
The é is two UTF-8 bytes and the emoji is four. A naive implementation using btoa alone throws on both.
URL-safe output
Options
URL-safe alphabet
Result
No +, / or = characters
Those three are reserved or awkward in URLs. The substitution is what makes JWT segments safe to put in a query string.
Decoding without padding
Base64
SGVsbG8
Result
Hello
The padding is restored before decoding. Many systems strip trailing equals signs, so rejecting unpadded input would fail on perfectly good data.
Frequently asked questions
Is Base64 a form of encryption?
No, and treating it as one is a real security mistake. It is a reversible encoding with no key, anyone who has the string can decode it in seconds. Credentials Base64-encoded in a config file or a header are stored in plain text for every practical purpose.
Why does encoding make my data bigger?
Because three bytes are represented by four characters, an increase of one third, plus padding. That is the cost of making binary data survive systems that only handle text, email bodies, JSON strings, data URIs.
What is the URL-safe variant for?
Standard Base64 uses + and /, which are reserved in URLs, and = which is awkward in query strings. The URL-safe alphabet substitutes - and _ and drops the padding, so the value can be dropped into a URL or a filename with no further escaping. JWTs use it for exactly this reason.
Why do other Base64 tools fail on emoji?
Because they call btoa directly, which is defined over Latin-1 and throws on any character above code point 255. The fix is to convert to UTF-8 bytes first, which is what happens here, so any Unicode text encodes and decodes cleanly.
Can I encode a file with this?
Not here. This works on text. For images there is a dedicated Base64 to image converter, which handles the data URI wrapper as well as the encoding.