Base64 Encoder and Decoder

What this tool does

Base64 writes arbitrary bytes with 64 harmless characters, so that binary data can travel through places that only accept text, such as JSON fields, HTML attributes or email bodies. It is an encoding, not encryption: anyone can decode it.

The tool encodes text or a file, and decodes Base64 back to text or to a file. It works with the standard alphabet and with the URL-safe alphabet, both defined in RFC 4648, and writes and reads data URIs. Decoded images are previewed, PDFs can be opened, and every recognized file is saved with the right extension.

How to use it

1. Choose the direction: encode or decode.
2. Type or paste the text. To encode a file of up to 20 MB, choose it with the file field instead.
3. For encoding, choose the alphabet and whether the result ends with = padding.
4. Copy the result or download it. After decoding, the download contains the decoded bytes, so this is how you restore a file. For an image or a PDF the file gets its proper extension, such as .png or .pdf.
5. For CSS or HTML, turn on “Output as a data URI” to get data:image/png;base64,… ready to paste into url() or an src attribute.

When decoding you do not need to say which alphabet the text uses. The tool recognizes it, accepts text with or without padding, ignores spaces and line breaks, and removes the prefix of a data URL.

How the result is derived

Text is first converted to bytes with UTF-8. The bytes are then taken in groups of three, which are 24 bits. Each group is split into four parts of 6 bits, and each part selects one of the 64 characters of the alphabet. Three bytes therefore become four characters, and the encoded form is about one third longer than the data.

If one or two bytes are left at the end, they produce two or three characters. Padding with = fills the last group up to four characters, so that the length of padded Base64 is always a multiple of four.

Decoding reverses the steps. If the decoded bytes are valid UTF-8, they are shown as text. If they are not, the data is something else, for example an image, and the tool shows the first bytes in hexadecimal instead of inventing characters.

Worked example

The word “foo” consists of the bytes 66 6f 6f in hexadecimal. As bits that is 011001 100110 111101 101111, four groups with the values 25, 38, 61 and 47. In the alphabet these are the characters Z, m, 9 and v.

f      -> Zg==
fo     -> Zm8=
foo    -> Zm9v
foob   -> Zm9vYg==
fooba  -> Zm9vYmE=
foobar -> Zm9vYmFy

The two alphabets differ only where the values 62 and 63 occur. The four bytes fb ff bf fe give +/+//g== in the standard alphabet and -_-__g in the URL-safe alphabet without padding.

Reference: Base64 variants

The URL-safe alphabet exists because + and / have a meaning in URLs. The padding character = has one as well, which is why formats such as JSON Web Tokens leave it out; the length of the text tells the decoder how many bytes the last group holds.

Some formats break Base64 into lines. The standard says that encoders must not add line breaks unless the format that uses Base64 asks for them. This tool writes one line and accepts line breaks when decoding.

A data URL, or data URI (RFC 2397), has the form data:image/png;base64, followed by the data. The tool removes such a prefix before decoding and reports the media type it found. When it writes one, it always uses the standard alphabet with padding, as RFC 2397 refers to the Base64 of MIME (RFC 2045), and takes the media type from the file’s first bytes, otherwise from the type your browser reports for the file; text is labeled text/plain;charset=utf-8.

Recognizing decoded files

A file name or a data URI label can be wrong; the first bytes of the data rarely are. After decoding, the tool compares them with the byte patterns that browsers use to recognize files, from the WHATWG MIME Sniffing Standard. If a data URI claims one type and the bytes show another, the tool says so.

The preview and the opened PDF come from the decoded bytes in the page’s memory, through a temporary blob: address that exists only in your browser. Other data is shown as text when it is valid UTF-8, and otherwise as hexadecimal and saved as decoded.bin.

Common mistakes

• Treating Base64 as protection. It hides nothing; use encryption for secrets.
• Decoding URL-safe text with a decoder for the standard alphabet, or the other way round. The characters - and _ are then reported as invalid.
• Encoding text with another character set than UTF-8 in one program and decoding it as UTF-8 in another. Letters outside ASCII then come out wrong.
• Losing characters when copying. Base64 with 1, 5 or 9 characters and so on cannot exist, because one character alone holds only 6 bits. The tool reports such text as incomplete.
• Putting standard Base64 into a URL without percent-encoding. A + in a query string is read as a space.

Sources

• RFC 4648: The Base16, Base32, and Base64 Data Encodings
• RFC 2397: the data URL scheme
• WHATWG MIME Sniffing Standard