Base64 Encoder and Decoder

Base64 exists to move binary data through channels that only reliably carry text, such as email bodies, JSON string fields, and URLs. It is an encoding, not a cipher, and treating it as one is a recurring security mistake. This page encodes and decodes locally.

How to use it

Pick Encode to Base64 or Decode from Base64.
Drop in a .txt or .b64 file. The transform runs in the page.
Download the encoded or decoded text.

What Base64 actually does

The encoder takes three bytes of input at a time, which is 24 bits, and re-expresses them as four characters drawn from a 64-character alphabet, six bits each. Four output characters for every three input bytes is where the well-known 33 percent size increase comes from. Encoding a 3 MB file produces roughly 4 MB of text.

When the input length is not a multiple of three, the final group is padded with one or two = characters so that the output length stays a multiple of four. That is all the padding does. It carries no data and exists purely so decoders know where the stream ends.

Base64 is not encryption, and this matters

Anyone can decode Base64. There is no key, no secret, and no computational cost to reversing it. Storing a password, an API token, or a connection string as Base64 provides no protection whatsoever beyond making the value unreadable at a glance.

The confusion is common enough to be a genuine source of breaches, usually because a credential was Base64-encoded into a config file or a JWT payload and treated as protected. A JSON Web Token, for instance, has a Base64url-encoded payload that anyone holding the token can read. The signature prevents tampering; it does not provide confidentiality.

Alphabet variants and line wrapping

Standard Base64 uses + and / as its last two characters. Both are problematic in URLs, where + can be interpreted as a space and / is a path separator. The URL-safe variant defined in RFC 4648 substitutes - and _ instead, and usually drops the padding. If a decode fails on a value pulled from a query string or a JWT, this substitution is the first thing to check.

MIME-oriented encoders also insert a line break every 76 characters, which is required for email transport but breaks naive decoders that do not strip whitespace. Encoded output here is emitted as a single unbroken line, and the decoder tolerates whitespace in its input.

Unicode handling

Base64 operates on bytes, not characters, so any text has to be turned into bytes first. The browser btoa function fails outright on characters above U+00FF, which is why naive implementations break on emoji, accented characters, and any non-Latin script. Text here is encoded as UTF-8 before Base64 is applied, and decoded back through UTF-8, so the round trip is safe for arbitrary Unicode.

At a glance

Accepted input	.txt, .b64
Alphabet	Standard RFC 4648 with padding
Text encoding	UTF-8 before encoding, after decoding
Size change	Roughly plus 33 percent when encoding

Frequently asked questions

Is Base64 a way to secure data?

No. It is a reversible encoding with no key. Anyone who has the encoded string has the original data. Use actual encryption if you need confidentiality.

My decode fails on a value from a URL or a JWT. Why?

It is almost certainly Base64url rather than standard Base64. Replace - with + and _ with /, then add = padding until the length is a multiple of four, and it will decode.

Why did my file get bigger after encoding?

That is inherent to the format. Four output characters represent every three input bytes, so encoded data is about a third larger. It is the price of making binary data safe to put in text.

Does it handle emoji and non-Latin text correctly?

Yes. Input is converted to UTF-8 bytes before encoding, which avoids the character range error that the raw browser API throws on anything above U+00FF.

CSV, JSON, YAML, XML: choosing a data format — Every conversion between these formats loses something. Knowing what, in advance, prevents most of the resulting bugs.