Base64 Decode: Base64 to Text

Encode text as Base64 →

How do you decode a Base64 string?

Base64 decoding reads those characters back as the bytes they stand for. Base64 exists to carry data through channels that accept only US-ASCII text. It is an encoding, not encryption: any decoder reverses it.

1. Strip any line breaks. A decoder ignores every character that is not in the alphabet.
2. Take the characters 4 at a time and look each one up: its index is a 6-bit number.
3. Join the 4 numbers into 24 bits and read them as 3 bytes.
4. Drop the bits a = stands for; they carry nothing.
5. Read the bytes as UTF-8 text. SGk= becomes Hi.

Base64 to Text Conversion Table

Base64 writes data with 64 characters - A to Z, a to z, 0 to 9, plus (+) and slash (/) - and reserves the equals sign (=) for padding. Each row is one six-bit value and the character that stands for it, so a group's number and its character are the same lookup read in either direction. RFC 4648 s5 swaps the last two rows; the + at index 62 becomes - and the / at index 63 becomes _.

Padding in the final group

A final group of three bytes takes no padding; two bytes give three characters and one equals sign; one byte gives two characters and two equals signs. RFC 4648 requires the pad characters unless the specification that refers to it says otherwise, so a Base64 string whose length is not a multiple of four is incomplete.

The same value in each encoding

These rows are shared with the other encoders, so a value written here is the value every page in the family writes.

Every value below is the one the specification fixes, so a result that disagrees with a row here is a result to check.

Worked Example: SGk= to Text

One group of bits at a time, with the regrouping drawn out. The same twenty-four cells are cut at eight above and at six below, which is the whole of why 3 bytes become 4 characters.

Start with the first four characters, SGk=. Each one's index in the alphabet is a 6-bit number, and the four numbers written end to end are the bits in the second row. A byte is 8 bits and holds 256 values, 0–255; a nibble is 4 bits. Base64 reads three bytes (24 bits) at a time and writes them as four characters of six bits each, so the output runs four characters for every three bytes - about a third larger than the input.

The second row is the same run of bits cut every 6 instead of every eight. Each six-bit group is a number from 0 to 63, and that number is a row in the table above. Here they are 18, 6, 36, which name S, G, k. Nothing is lost in the regrouping: the same bits are read a different width, which is why the result reverses exactly.

UTF-8 encodes each character in 1 to 4 bytes. Characters 0–127 use one byte identical to ASCII, so ASCII text is valid UTF-8. That is why the byte count, not the character count, decides the length of the result — a character outside US-ASCII takes more than one byte and therefore more than one sixth of a group.

Check it in reverse

The value goes back the way it came. Four characters give their four indices, the indices give 24 bits, and the bits give 3 bytes again. Nothing is carried alongside the result: the alphabet says what each character is worth and the pad says how much of the last group was real. To verify the result by hand, encode the decoded text back to Base64 and compare it with what you started from.

Worked examples: Base64 to text

Each example gives the value first, then the working. Click a value to load it in the converter.

Every example above reverses exactly - write the same bytes back as six-bit groups.

What Makes a Base64 String Fail to Decode?

Which alphabet is in use?

This page writes the standard alphabet. The URL-safe alphabet of RFC 4648 section 5 keeps the first 62 characters and swaps plus for minus (-) and slash for underscore (_), so the result passes through a URL or a file name unchanged.

Are the line breaks part of the result?

No. RFC 4648 forbids adding line breaks to Base64 output. MIME is the specification that asks for them: RFC 2045 wraps at no more than 76 characters a line and tells decoders to ignore every character that is not in the alphabet.

What can the result be pasted into?

Anything that carries plain US-ASCII text. The alphabet was chosen so that every character in it survives a mail gateway, a JSON string and a form field without being rewritten on the way.

Is this the encoding you need at all?

The three schemes protect different things and are not interchangeable. these encodings are not interchangeable - how these encodings differ sets out which does what.

Base64 to Text in Code

Both standard libraries carry this conversion, so the one-liner below is the whole job. Check the result against the table above before you trust it in a pipeline.

Python: base64.b64decode('SGk=').decode()

JavaScript: decodeURIComponent(escape(atob('SGk=')))

Common Mistakes

• Treating the result as protection. Base64 exists to carry data through channels that accept only US-ASCII text. It is an encoding, not encryption: any decoder reverses it.
• Losing the pad. RFC 4648 requires the pad characters unless the specification that refers to it says otherwise, so a Base64 string whose length is not a multiple of four is incomplete.
• Pasting a string that carries the other alphabet: a minus sign or an underscore in the middle of a value means it was written for a URL, and this page will name the character it cannot read.

Frequently Asked Questions

Related Conversions

• if the decoded text still shows entities, decode & and A back to characters.
• when the Base64 turns out to be a picture, turn a Base64 string into an image file.
• if the string came out of a query string, turn %20 back into a space first.
• to put the decoded value back into a link, make a string safe inside a URL.
• going the file route instead, turn an image file into Base64 text.
• before the decoded text goes into a page, replace the characters that break HTML.

The rest of the family sits on every encoder and decoder in this family.