Base64 Decoder and Encoder

What Base64 is for

Base64 represents arbitrary binary data using 64 printable ASCII characters. It exists because many protocols were designed to carry text and will corrupt or reject raw bytes: email bodies, JSON string fields, URLs, HTTP headers, and data URIs in CSS all need binary content expressed as safe characters.

The cost is size. Three bytes of input become four characters of output, so encoded data is about 33 percent larger, plus padding. That overhead is the reason you encode at the boundary and decode as early as possible rather than storing data encoded.

Base64 is not encryption

This matters enough to state plainly. Base64 is an encoding, not a cipher. It provides no confidentiality whatsoever, and anyone can reverse it with the button above. Data that needs protecting must be encrypted; encoding it merely makes it unreadable to a casual glance. Treat a Base64 blob in a config file as though it were printed in the clear, because effectively it is.

The Unicode trap

The browser's built-in btoa function only accepts characters in the range 0 to 255, so calling it on text containing an accented letter, a non-Latin script or an emoji throws an error, and the workarounds people paste from forums often mangle the result instead.

This tool encodes text to UTF-8 bytes first, then Base64-encodes those bytes, which is what every other language does by default and what any consumer will expect. Decoding reverses both steps. The practical result is that "café", "日本語" and emoji all round-trip exactly.

Standard and URL-safe alphabets

Standard Base64 uses + and / as its final two characters, both of which have meaning inside URLs, and = for padding, which is also reserved. The URL-safe variant defined in RFC 4648 substitutes - and _ and usually drops padding.

Decoding here accepts either form without being told which: the substitutions are normalised and missing padding is restored before decoding. Encoding produces the URL-safe form when the option is ticked. JSON Web Tokens use the URL-safe alphabet without padding, which is why a raw JWT segment often fails in a strict decoder.

Common failures

• Wrapped lines. Base64 from an email header or a PEM file arrives split across lines. Whitespace is stripped here automatically.
• PEM headers. A certificate includes -----BEGIN CERTIFICATE----- lines that are not part of the encoded data and must be removed before decoding.
• Truncation. An input length that leaves a remainder of one when divided by four cannot be valid, and is reported as such.
• Double encoding. If decoded output still looks like Base64, it probably is. Decode again.

Questions

Is Base64 a form of encryption?

No. It is a reversible encoding with no key and no secrecy. Anyone can decode it instantly. Data that needs to stay private must be encrypted; Base64 only makes it non-obvious to a human reading the file.

Why does my emoji or accented text break in other tools?

Because the browser's btoa function only handles characters up to code point 255. This tool converts text to UTF-8 bytes before encoding, so any Unicode text round-trips correctly.

What is URL-safe Base64?

A variant that replaces plus with hyphen and slash with underscore, and usually omits padding, so the result can appear in a URL or filename safely. JSON Web Tokens use it. Decoding here accepts either alphabet automatically.

How much larger does Base64 make my data?

Roughly 33 percent, since every three bytes become four characters, plus up to two padding characters. That is why it is used at protocol boundaries rather than for storage.

Can I decode a PEM certificate?

Yes, but remove the BEGIN and END header lines first. Those are delimiters, not part of the encoded data. Line breaks within the body are handled automatically.