Base64 Decode — Base64 to Text

What Base64 Decoding Actually Does

Base64 decoding reverses an encoding, not an encryption. Every four Base64 characters represent three bytes of the original data, and the decoder simply reads the characters back through the standard 64-character alphabet and reassembles the bytes. There is no key, no secret and no protection involved — which is the single most important thing to understand about it.

That means Base64 is not a way to hide anything. If you have found a Base64 string in a configuration file, a URL or an API response, decoding it takes one click, for you and for anyone else. Data that needs to stay secret needs encryption; Base64 only makes binary data survive a text-only channel.

A worked example, in reverse

Take the encoded string:

Split it into groups of four: SGVs, bG8g, d29y, bGQ=. Each character maps to a 6-bit value, so four characters give 24 bits, which regroup into three 8-bit bytes. The trailing = in the last group says that group encodes fewer than three bytes. The result:

Why Your Base64 String Will Not Decode

Decoding is mechanical, so a failure almost always means the input is not quite what the decoder expects. In order of how often they occur:

1. Missing or wrong padding. A standard Base64 string's length is a multiple of four, padded with one or two = characters if necessary. Many systems strip the padding because it is redundant; strict decoders then reject the string. Adding = until the length is a multiple of four fixes it.
2. It is URL-safe Base64, not standard. The URL-safe variant defined in RFC 4648 §5 replaces + with - and / with _ so the string can travel in a URL without escaping. Translate those two characters back before decoding. JWTs use this variant, which is why a raw JWT segment fails in a standard decoder.
3. Line breaks and whitespace. MIME Base64 wraps at 76 characters, and strings copied out of an email header or a PEM file carry those newlines. Most decoders ignore whitespace; strict ones do not.
4. A data URI prefix.data:image/png;base64, is not part of the payload. Everything up to and including the comma has to go.
5. It was double-encoded. If decoding produces another string that still looks like Base64 — long, alphanumeric, maybe ending in = — it probably is. Decode again.
6. It is not Base64 at all. Hexadecimal, Base32 and Base58 all look similar at a glance. Hex uses only 0–9 and a–f; Base58 omits 0, O, I and l and never uses + or /.

The Base64 Variants You Will Meet

Decoding Text That Is Not Plain ASCII

Base64 encodes bytes, not characters, so decoding gives you bytes back — and turning bytes into readable text requires knowing the character encoding. If the original was UTF-8, the decoded bytes are UTF-8 and everything renders correctly. If it was UTF-16 or a legacy code page, interpreting the result as UTF-8 produces mojibake: café arriving as café is the classic symptom, and it means the bytes are right and the interpretation is wrong.

This decoder treats output as UTF-8, which is correct for the overwhelming majority of modern data. Seeing replacement characters usually means the source was not text at all — a decoded PNG or ZIP will always look like noise, because it is.

Where Base64 Strings Turn Up

• JWTs. Three URL-safe Base64 segments separated by dots. The first two decode to readable JSON; the third is a binary signature and will not.
• HTTP Basic authentication. The Authorization header contains Basic followed by Base64 of username:password. That is encoding, not protection — it is exactly why Basic auth requires HTTPS.
• Data URIs. An image or font embedded directly in HTML or CSS.
• Email attachments. SMTP is a text protocol, so every binary attachment travels Base64-encoded.
• Certificates and keys. Everything between the BEGIN and END lines of a PEM file is Base64-encoded DER.
• API payloads. Binary fields inside JSON, which has no binary type.

Frequently Asked Questions

Is Base64 decoding the same as decrypting?

No, and the distinction matters. Decryption requires a key that only authorised parties hold. Base64 decoding requires nothing at all — the transformation is public and reversible by anyone. Anything protected only by Base64 is not protected.

Is my data uploaded when I decode it here?

No. The decoding runs in JavaScript in your browser, so the string you paste never leaves the tab. That is worth knowing if you are decoding a token or a header from a real system.

Why does the decoded output look like random characters?

Because the original was not text. Base64 encodes any bytes at all, and an image, a PDF, a compressed archive or a cryptographic signature decodes to binary that no text renderer can display sensibly. Look at the first few bytes: PNG, %PDF or PK tells you what you actually have.

How do I decode a JWT?

Split it on the dots and decode the first two segments separately — they are URL-safe Base64, so replace - with + and _ with / first, and add = padding to make the length a multiple of four. The third segment is a signature over the first two and is not meant to be readable. Decoding a JWT does not verify it; verification needs the signing key.

Can I decode Base64 back to an image file?

Yes — use the Base64 to Image converter, which decodes the string, previews the result and lets you download it as a file. This page is for text output. To go the other way, the Base64 encoder and the image to Base64 converter handle text and image input respectively.