Base64 Decode

Base64 copied from emails, logs and config files rarely arrives clean. The decoder handles the usual mess:

• Line breaks and spaces are removed first, so Base64 wrapped across several lines, as in email sources, decodes as one string.
• Missing padding is fine. SGVsbG8 decodes to Hello just as SGVsbG8= does.
• Leading and trailing whitespace is ignored.

Any of these makes the whole input fail:

• URL-safe characters. - and _ aren't in the standard alphabet. Change - to + and _ to /, so Pj4-Pz8_ becomes Pj4+Pz8/, which decodes to >>>???. For a whole JSON Web Token, the JWT Decoder does this conversion for you.
• A data URI prefix. Remove the data:text/plain;base64, part at the start, so only the characters after the comma remain.
• Two values pasted together. Padding in the middle, as in SGk=SGk=, is rejected. Decode each value on its own.
• A truncated string. If the length leaves a single character over after dividing into groups of four, as with T, part of the data is missing.

The decoded bytes are read as UTF-8 text. When they aren't valid UTF-8, each bad sequence is shown as the replacement character � instead of an error. Two situations cause this:

• The data was never text. Images, PDFs, compressed or encrypted data decode to a jumble of symbols and �. The Base64 is probably fine, but this page only shows text.
• The text used another encoding. 6Q== is é in Latin-1, a single byte, and shows as �. The UTF-8 form of é is w6k=, which decodes correctly. If an older system produced the Base64, this is the likely cause.

Decoding shows the content exactly, including its formatting. A decoded JSON payload keeps whatever spacing it had, which is often none. Paste it into the JSON Formatter to read it.

If the result is itself a string of letters, digits, + and /, it may have been encoded twice. Decode it a second time.