Decode from Base64 format

Overview

Base64 is a reversible shape shift, and this tool is the reverse half of the trip: it takes the printable text that an encoder produced and turns it back into the original data. Paste a string, pick the settings that match where it came from, and the decoded result is ready to read or copy. When the payload is a binary like an image or an archive, its Base64 text lives in a plain file: the file form on this page takes that file and hands back the original binary as a download. The matching encoder lives on the sister site, one link away.

Advanced options

• Character set: Base64 moves bytes, not letters, so the decoded result only reads correctly if you know which character set it was stored in before the encoding. Pick the one that matches your source: UTF-8 for modern text, Windows-1252 or an ISO-8859 variant for older documents, or AUTO-DETECT to let the tool decide (it shows what it settled on right next to the list, and assumes UTF-8 when it cannot tell). If the output looks like a scrambled alphabet, this is the first dial to turn. Files are exempt: binary data is decoded as-is, no conversion applied.
• Decode each line separately: By default the whole input is one continuous payload: line breaks and spaces are stripped before the decoding, so a string wrapped across lines, copied straight out of an email, just works, and the URL-safe characters - and _ are accepted in place of + and /. Tick this box when the input is a list of independent entries: each line is then decoded on its own, and the results come back one per line. The file form offers the same option.
• Live mode: Flip this on and the decoding happens in your browser as you type, re-running on every keystroke with nothing sent to our servers. It honors the per-line option and works with UTF-8 only, so the character set list stays locked while it is on, and the decode button stays disabled until you switch back.

Safe and secure

Everything runs over an encrypted HTTPS connection, and nothing you submit is kept: uploaded files are deleted the moment they are processed, and the downloadable result disappears right after your first download attempt or 15 minutes of inactivity, whichever comes first. The contents of what you send are never stored; the only processing beyond the conversion is a security scan of uploaded files, which exists to block malicious or inappropriate content. With live mode on, your text never leaves the browser. The full details live in our privacy policy, linked in the footer below.

Completely free

Everything on this page is free to use - the complete character set list, the file uploads, and the live mode included. No account, no software to install, no paywall: for a task this small, that is how it should be.

Base64 explained

Some data simply cannot travel through a text-only channel: a photo, an archive, a hash, a chunk of binary that would make a 7-bit email connection choke. Base64 is the translator for moments like this. It rewrites any sequence of bytes into plain, printable text, so the data can sit in an email body, a JSON document, an XML file, or a URL and arrive exactly as it left. The translation is fully reversible: every byte comes back, in the same order, with nothing lost along the way.

The whole format fits in one sentence: three bytes in, four characters out. The price is a result that is about a third bigger than the original. The reward is a string that looks like text, behaves like text, and survives channels that would destroy raw bytes. And it is worth pinning down early what Base64 is not: it is not encryption, and it is not compression. It is a reversible shape shift, and that is the entire job.

Why 64, and why those characters

A byte holds 8 bits, but old text channels, email above all, only carried 7-bit ASCII safely. The trick is to pick an alphabet of printable characters that survives any such trip, and to size it so the math comes out clean. With 64 characters, each encoded character carries exactly 6 bits, and 24 is divisible by both 8 (the byte) and 6 (the character): three input bytes become four output characters with nothing left over. The name is just the base of that character math, like base 10 for our digits.

The standard alphabet is the 62 alphanumeric characters, A to Z, a to z, and 0 to 9, with + and / as the last two. The specification adds a 65th character, =, which is not in the alphabet at all: it only ever appears at the end, as padding. The choice was deliberate. The whole set is printable; it is common to every text system; and the MIME specification notes that it is spelled identically in every version of ISO 646, including US-ASCII, and in every version of EBCDIC. That last property is what keeps the data intact while it crosses the old 8-bit-unclean machinery of the internet.

Encoding, step by step

The encoder is a four-step assembly line. It reads the input three bytes at a time and merges each triplet into a single 24-bit string. That string is cut into four chunks of 6 bits. Each chunk is a number from 0 to 63, and each number is looked up in the table above. Four numbers in, four characters out.

Watch it happen on the word foo, which arrives as the byte values 102, 111, and 111 (hex 66, 6F, 6F). Laid end to end, the 24 bits are 01100110 01101111 01101111. Cut into sixes, that is 011001, 100110, 111101, and 101111, which are 25, 38, 61, and 47. The table says those are Z, m, 9, and v, so foo encodes to Zm9v, and any Base64 decoder in the world will turn it back into the original three bytes.

The rest of the input is processed the same way, triplet after triplet, until nothing is left. Only the final group, when it holds fewer than three bytes, needs a special move.

Padding: the = at the end

The input is always a whole number of bytes, but three does not always divide it evenly. When one or two bytes are left over at the tail, the encoder still has to finish a full group of four characters. It fills the missing bits with zeros, does the lookups as usual, and replaces the characters the padding bits would have produced with = signs. Exactly three endings are possible:

So fo, two bytes, becomes Zm8=, and the lonely f becomes Zg==, while foo needs no padding at all. The decoder knows exactly what to do with the pads: each = means eight more zero bits to throw away. The pads only ever sit at the very end, and there are at most two of them. The MIME spec even uses this as a feature: since = cannot appear anywhere else, a padded payload announces its own ending, so the receiver can tell the data was not truncated in transit. And for the smallest case: the empty input encodes to the empty output. Even nothing gets a perfect round trip.

Decoding: the assembly line in reverse

Decoding is the same machine running backwards, and it is just as mechanical. Take four characters, look the real ones up (a pad stands in for six zeros), write out the 24 bits, and hand back the first 16 bits if one pad is present, or all 24 if there are none. Four characters in, three bytes out; two bytes out with one pad; one byte out with two. The zero bits the encoder added are the only thing thrown away, and every other bit is exactly what went in. That is what reversible really means here: the format itself is lossless, and the only things that can hurt your data are a channel that corrupts the string, or a decoder that quietly gives up.

That is why the standard is strict about one thing: characters that are not in the alphabet. RFC 4648 says a decoder must reject a payload that carries any character outside the 64, unless the surrounding specification explicitly allows it. The reason is practical, not pedantic. A decoder that quietly swallows foreign characters can be tricked: the smuggled characters become a hidden side channel, and that trick has been used to hide data from filters and to poke at decoder bugs. The famous exception is MIME itself, which predates the standard and says the opposite: ignore every character outside the alphabet, and that is how the line breaks get through an email attachment. When you validate input yourself, the modern rule is the right one: if your string carries an @, a space, or anything else that is not in the table, it is not clean Base64.

Line breaks and the 76-character rule

You will often meet Base64 wrapped into lines, and the habit comes from email. Old SMTP machinery had line-length limits, so MIME wraps the payload at 76 characters per line with a CRLF break, and the older PEM format, the one that carries certificates and keys, wraps at 64. RFC 4648's rule for new code is the opposite: add no line breaks at all unless the format you are implementing says to. In practice, the decoder does not care. A line break is just a character outside the alphabet, so a MIME-wrapped payload, a PEM block, and one long unbroken string all decode to the same bytes. If you paste Base64 from anywhere, strip the line breaks first and be done with it.

The wrapping has a small cost, and it shows up in size math. Without line breaks, Base64 is exactly four thirds of the original, about 33 percent bigger. Wrapped at 76 characters with CRLF breaks, it is about 37 percent bigger, which is why a file that should be 100 KB often arrives as roughly 137 KB of text. The math always checks out.

Base64URL: the URL-safe twin

The standard alphabet has two characters that do not play well with URLs. A + in a query string is traditionally read as a space, and / is a path separator, so a raw Base64 string in a URL needs percent-escaping for both, plus the = pads. Section 5 of RFC 4648 defines the fix: the URL and filename safe alphabet, where + becomes - and / becomes _. The pads usually go away too, because a missing pad can be worked out from the length. The RFC says flatly that this should not be called plain Base64: it is a different encoding, usually written base64url.

In practice, the two are one swap apart, in the dangerous direction. Feed a base64url string to a standard decoder and it goes wrong, because - and _ are not in the standard alphabet: a lenient decoder discards them and returns a shorter, wrong byte string - or, when the remainder is too short to stand alone, an error - while a strict one rejects the whole payload. The correct dance is to swap - back to + and _ back to /, top up the missing pads, and only then decode. This is the dialect you meet in JSON Web Tokens (JWT), OAuth state strings, and the IDs of a certain very large video site.

A quick field guide

Before you reach for a tool, you can read a lot of the string yourself. A few checks tell you whether a payload is Base64 at all, and what it hides:

• Look at the characters. Standard Base64 uses only A to Z, a to z, 0 to 9, +, and /; the URL-safe twin uses - and _ in place of those two. Any other symbol, or a stray space, means it is not clean Base64.
• Check the pads. The = signs, if present, sit only at the very end, and there are at most two. A pad in the middle of the string is a red flag.
• Count the length. With pads, the length is always a multiple of 4. Without pads, dividing the length by 4 leaves a remainder of 0, 2, or 3. A remainder of 1 is impossible, because a single character only carries 6 bits and a byte needs 8.
• Estimate the size. Each group of 4 characters holds 3 bytes, minus one byte per = sign. So Zm9vYmFy, eight characters with no pads, is 6 bytes, and Zm9vYg==, eight characters with two pads, is 4.

One last field trick, and the most useful. The encoder must zero the padding bits, but a lenient decoder does not check them. The payload Zg== decodes to the single byte f, and so does Zh==: the low bits of the last character are padding in both cases, so both spell the same byte. The standard calls the zero-bit version the canonical form, and it lets strict decoders reject the other one. Two strings, one payload. If two systems disagree about a Base64 value, the pad bits are a good place to start looking.

What Base64 is not

• Not encryption. There is no key and no secret; anyone can turn a Base64 string back into bytes in a second. The RFC even mentions real incidents where people reported protocol exchanges that included an "encoded" password, convinced the encoding was hiding it. If the data is sensitive, protect it with real cryptography before you encode it, not after.
• Not compression. It goes the other way: the result is about 33 percent bigger than the input, and larger still once line breaks are added. Base64 buys you text safety, and it bills you for it in size.
• Not a character set. Base64 moves bytes, not letters. It does not know or care whether those bytes are UTF-8 text, a legacy one-byte encoding, or a JPEG. The "which charset is this?" question lives before the encoding and after the decoding, never inside it.
• Not one single encoding. The name covers a family: the standard alphabet, the URL-safe twin, payloads wrapped at 76 or 64 characters, variants that skip the pads, and a handful of oddballs (IMAP, for instance, uses a comma in place of the alphabet's / when encoding international mailbox names). When two systems disagree on a payload, a dialect difference is usually the culprit.

The fine print

The primary sources are short and readable. RFC 4648, The Base16, Base32, and Base64 Data Encodings (2006), is the current standard: both alphabets, the padding and line-break rules, the strictness rules, and a set of official test vectors, like foo becoming Zm9v, that implementations check themselves against. Behind it stands RFC 2045, the 1996 MIME specification where the 76-character line rule and the ignore-stray-characters leniency come from, and RFC 1421, the deprecated Privacy Enhanced Mail spec that started the family with 64-character lines. An earlier unification attempt, RFC 3548, was replaced by RFC 4648.

That is the whole story: 64 characters, three bytes in and four characters out, = to finish the tail, and a perfect round trip. Every tool, library, and online converter you will ever meet is just a doorway into this. Once you can look at a Base64 string and see the bytes standing behind it, nothing about the format surprises you anymore. And when you are ready to write the decoder yourself, the programming-language articles just below this section hand you the same 64 characters as working code: one complete guide per language.