Base64 Encode / Decode

These tools Base64-encode and decode text, images and files. Everything happens inside your browser, so nothing you paste or upload is sent across the internet. Paste text into the first tool, or hand a file to the second and get its Base64 back, ready to copy or download.

What Base64 is

Base64 encoding is a way of converting binary data to and from text. Some computer systems, especially older ones, and a number of transmission and storage formats handle text far more reliably than raw binary. Base64 represents binary information such as images, files or arbitrary data using a set of 64 printable ASCII characters, which makes it safe to move through those systems.

The character set is the uppercase letters A to Z, the lowercase letters a to z, the digits 0 to 9, and two more characters, normally + and /. The = symbol is used as padding at the end of the output so the encoded string comes out the right length. The table below shows the characters and their numeric values under RFC 4648.

Why the output is bigger

Modern computers are byte-based, at 8 bits per byte, while Base64 represents data in 6-bit values mapped onto those 64 characters. Three bytes of input carry 24 bits, which divides evenly into four 6-bit blocks, so three bytes become four characters. Base64 output is therefore about 4/3, or roughly 1.33 times, the size of the original: a 33 percent increase before anything else is added.

In real terms, one kibibyte of data becomes 1,368 characters, and a one megabyte image becomes about 1.33 MB of text. If the encoder also wraps lines at 76 characters, which the MIME standard for email requires, the line breaks push the overhead to about 37 percent.

Worked examples

The text 'Dog' encodes as 'RG9n'. Its three ASCII characters carry 3 × 8 = 24 bits, which split cleanly into four 6-bit blocks.

Most of the time the input does not divide by three, leaving 2 or 4 bits over at the end. One or two '=' characters are then added to stand in for the missing group. 'Do' encodes as 'RG8=':

And 'Dogs' encodes as 'RG9ncw==':

The rule is short: input length divisible by three needs no padding, two leftover bytes need one '=', and one leftover byte needs two. That is also why a valid Base64 string can never be one character longer than a multiple of four, and why the decoder here rejects a length that leaves a single leftover character.

Where Base64 is used

E-mail attachments. SMTP was originally designed to carry 7-bit ASCII only. Encoding binary data as Base64 is what lets an older SMTP server move a photograph or a PDF intact, and it is still what every MIME attachment does today.

Embedding binary data in text files. Text formats dominate data transfer, and Base64 lets binary ride inside them. Binary can be Base64-encoded and dropped into JSON or XML, and images or PDFs can be embedded directly in HTML or CSS as a data URI, which is a string of the form data:image/png;base64,… used in place of a file path. Encode an image with the second tool above and it hands you exactly that string.

HTTP headers and tokens. HTTP Basic authentication sends the username and password as Base64. JSON Web Tokens are three Base64 sections joined by dots. Both rely on the encoding to keep bytes safe through headers that would otherwise mangle them.

Base64 is not encryption

This is the misunderstanding worth spelling out. Base64 provides no secrecy whatsoever. It is a reversible mapping with no key, and anybody can decode it in one step, including with the tool on this page. A password sent as Base64 in an HTTP Basic header is transmitted in the clear as far as security is concerned, which is why Basic auth is only acceptable over HTTPS.

Encoding solves a transport problem, not a confidentiality one. If the data needs to stay private, encrypt it first and then Base64 the ciphertext if the channel demands text.

The URL-safe variant, and other alphabets

The standard alphabet ends in + and /, both of which have meaning inside a URL, and = has meaning in a query string. RFC 4648 therefore defines a URL-safe variant that swaps + for - and / for _, usually with the padding dropped entirely. JSON Web Tokens use it, as do most URL parameters carrying encoded data. The decoder on this page accepts both alphabets and ignores whitespace, since that is what people actually paste out of emails, JSON files and terminal output.

Base64 is not the only such scheme. Base32 uses a smaller alphabet that survives case-insensitive systems, at a cost of 1.60 times the original size. Ascii85 packs four bytes into five characters for 1.25 times, and appears inside PDF and PostScript. Base58 drops the characters people confuse when reading aloud, which is why Bitcoin addresses use it.

Character sets, and where decoding goes wrong

Base64 encodes bytes, not characters, so the text has to become bytes first and the character set decides how. In UTF-8 an accented letter such as é is two bytes and an emoji is four, so the encoded output is longer than the visible character count suggests. Choosing ASCII or ISO-8859-1 restricts you to one byte per character, and this tool says so rather than silently substituting a question mark when a character has no byte in that set.

The same choice matters on the way back. Decoding produces bytes, and turning those bytes into readable text needs the same character set they were encoded with. Text that comes back as mojibake usually means the byte stream is fine and the character set is wrong.

Reading the results on this page

The panel reports how many characters or bytes came out, what went in, and the size change between them, along with the number of padding characters and how many four-character blocks the result contains. The output box below it holds the full result, with copy and download buttons. For files, encoding shows the Base64 text and, for an image, a preview and the data URI you can paste straight into HTML. Decoding a file downloads the reconstructed binary directly.