Base64 Encode and Decode

Base64 is not encryption and it is not compression. It is a way of writing arbitrary bytes using sixty-four characters that survive systems which only expected text — mail headers, JSON strings, data URLs, a token in a query string. The cost is size: every three octets become four characters, so the output is a third larger than the input, always. This page converts in both directions as you type, in either of the two alphabets the standard defines, and everything happens in your browser.

How it is calculated

3 octets → 4 characters, each character carrying 6 bits of the 24

The encoder takes the input three bytes at a time, treats those twenty-four bits as four groups of six, and looks each group up in a sixty-four character table. When the input does not divide by three, the last group is completed with zero bits and the output is padded with one or two "=" characters so that the length is still a multiple of four.

Source: RFC 4648 section 4 (Table 1) and section 5 (Table 2) — the base 64 alphabet and the URL and filename safe alphabet

Questions people ask

What is the difference between Base64 and base64url?

Two characters. The standard alphabet ends in "+" and "/", both of which mean something inside a URL and have to be escaped there. The URL and filename safe alphabet uses "-" and "_" in their place and is otherwise identical, so the same bytes come out the same length. The specification is explicit that the two are not interchangeable in name: base64url should not be called just "base64".

Can I drop the "=" at the end?

Only when whatever reads it knows how long the data is. The rule is that implementations must include the padding unless the specification that refers to them says otherwise — and several do say otherwise, which is why JSON Web Tokens carry no padding at all. The decoder here restores it for you either way.

Is Base64 a way to hide something?

No, and treating it as one is how secrets end up in logs. Anyone can decode it, this page included, without a key or a password. It changes the alphabet the bytes are written in and nothing else.

Why did my decode fail?

Three reasons cover almost every case: a character outside the alphabet slipped in, the length is one more than a multiple of four, which no valid encoding produces, or the bytes decoded cleanly but do not spell UTF-8 text. Line breaks from a wrapped block are fine — they are stripped before decoding.

Does it handle emoji and other non-Latin text?

Yes. The text is turned into UTF-8 bytes first, so an emoji becomes four octets and encodes like any other four octets. That is also why the output grows more than you might expect for scripts that take several bytes per character.

Related tools