How to decode Base64
- Paste the whole Base64 string into the input box. Spaces and line breaks copied from email clients or logs are ignored, so you do not have to clean the value first.
- Press Decode from Base64. The input stays in place, so you can correct it and try again without pasting twice.
- Copy the readable result. If the output looks like a URL, a JSON body or a configuration value, it is ready to use in your editor or terminal.
- Check the message under the buttons if the decode fails. It separates three cases: an illegal character, a length that Base64 cannot produce, and bytes that are binary rather than text.
Why Base64 decode fails, and how to fix it
A Base64 decoder is unforgiving by design: every character carries bits, so one wrong character corrupts the whole value. The tool reports the failure rather than returning a partially garbled result, and the message points at one of these causes.
- An illegal character. Base64 uses only A–Z, a–z, 0–9,
+,/and=. A string that contains a space in the middle of a value, an angle bracket or a smart quote has picked up something else. Copy the value again from its source instead of retyping it. - A length Base64 cannot produce. After whitespace is removed, a valid value has a length that is a multiple of four once padding is added. If exactly one character is left over, the copy is almost always truncated — a log line was cut off, or the final character was not selected when copying.
- Missing padding. Some systems strip the trailing
=or==. This decoder recalculates padding, so a value that lost its padding still decodes. - Binary payload. Base64 of an image, a PDF, an encrypted blob or a JWT signature is valid but does not decode to text. The tool says so instead of showing replacement characters, because a string of invisible control characters is worse than an honest error.
- Wrong alphabet. Hex dumps, percent-encoded URLs and HTML entities are not Base64. The Decode This page is a better starting point when you are not sure which encoding you have.
Standard, URL-safe and MIME Base64
Base64 has three everyday dialects, and a value pulled from a URL or an email may use any of them. This decoder accepts all three without configuration.
| Variant | Alphabet | Padding | Where you see it |
|---|---|---|---|
| Standard (RFC 4648 section 4) | + and / | = or == | data: URLs, JSON fields, most APIs |
| URL-safe (RFC 4648 section 5) | - and _ | Often omitted | JWT segments, query strings, filenames |
| MIME (email) | Standard alphabet | Wrapped at 76 characters | Email attachments, older SOAP and XML payloads |
The decoder normalizes URL-safe characters to their standard equivalents and removes line breaks before it converts anything. That means you can paste a complete JWT segment or a value that travelled through an email without editing it first.
What a decoded value can and cannot tell you
Decoding proves one thing: that the bytes form valid Base64. It does not prove who created the value, when it was created, or that it is safe to use. A decoded string is untrusted input like any other, and if you paste it into a template, a shell or a database query, it needs the same validation as any user-supplied text.
Decoding also does not repair a value. If the original text was encoded in a legacy character set such as GBK or ISO-8859-1, the bytes are still those bytes, and a UTF-8 decoder will reject them. This tool treats the output strictly as UTF-8 because that is what virtually every modern API, web page and JSON document uses. When the bytes are not UTF-8 text, the honest answer is the error message you get here, not a best-effort guess.
Frequently asked questions
How do I know if a string is Base64?
Three clues help: only the characters A–Z, a–z, 0–9, +, /, - and _ appear; the length is close to a multiple of four; and the value often ends with one or two =. None of this is proof, because short plain words can also be valid Base64 characters. Decoding is the only real test.
Why do I get an error instead of text?
The tool checks two things before it shows output: whether the characters form valid Base64, and whether the decoded bytes are valid UTF-8 text. A failure means the string is not Base64, is incomplete, or decodes to binary data such as an image or an encrypted value. The message names which of those applies.
Does Base64 decoding work for Chinese characters?
Yes, as long as the original text was UTF-8. For example, SGVsbG8g5LiW55WM decodes to Hello δΈη, and SHVncyDwn5GL decodes to Hugs π. The decoder validates the whole UTF-8 sequence, so a partially copied multi-byte character is reported instead of being silently replaced.
Why does the string end with = or ==?
Those characters are padding. Base64 works in groups of four output characters, and when the input byte count is not divisible by three, one or two = signs fill the last group. Padding carries no data; it only makes the length valid. Some systems drop it on purpose, which is why this decoder adds it back when needed.
Is there a size limit?
The practical limit is browser memory, not an artificial cap. Decoding converts the string in chunks, so a few hundred kilobytes are instant and a few megabytes take a moment. Very large encoded files are better handled with a command-line decoder, which can stream the input instead of holding it all in one tab.