How to decode Base64
- Paste your Base64 string into the box above.
- Padding, line breaks and surrounding quotes are handled automatically.
- The decoded text appears immediately below.
- If the result looks like nonsense, the string probably held binary data rather than text.
- Copy the decoded text, or download it as a file.
What this decoder tolerates
- URL-safe strings using hyphen and underscore instead of plus and slash.
- Missing padding, which is common in tokens and URL-safe output.
- Line breaks and indentation from a wrapped or copied block.
- Surrounding quotes, trailing commas and semicolons from source code.
- A data URI prefix, which is stripped before decoding.
- Full UTF-8 output, so accented characters and emoji come back correctly.
Base64 strings turn up everywhere
Once you start looking, encoded data is all over the systems you work with. An Authorization header holds Base64-encoded credentials. A JSON Web Token is three Base64URL segments separated by dots. A configuration file has a certificate wrapped in PEM markers. An API returns a file as a Base64 string rather than a binary body. A stylesheet contains a data URI for an icon.
Decoding is how you find out what any of it actually says, which is usually the fastest way to understand why something is not working.
Why decoders fail on real-world strings
Strings copied out of production are rarely clean. They arrive wrapped in quotes from a source file, split across lines by a terminal, missing their padding because the producer used the URL-safe form, or with a data:image/png;base64, prefix still attached.
A strict decoder rejects all of these. This one normalises first: it strips a data URI prefix, removes quotes and trailing punctuation, discards whitespace and line breaks, converts URL-safe characters back to standard ones, and re-adds the padding. Then it decodes. That is the difference between a tool that works on textbook input and one that works on what you actually have.
Inspecting a JSON Web Token
A JWT looks like xxxxx.yyyyy.zzzzz. The first two segments are Base64URL-encoded JSON. The header and the payload, and decoding them shows exactly what claims a token carries and when it expires. The third segment is a signature and will not decode to anything readable, because it is binary.
Decode the segments separately, splitting on the dots. Run the result through the JSON formatter to read it properly. Remember that a token's payload is not secret. Anyone holding the token can read it, which is why sensitive data should never go in one.
When the output looks like nonsense
Three causes account for nearly all of it. The string may have decoded correctly but held binary data. An image, a font, a compressed archive, in which case the bytes are simply not text. It may be double-encoded, so decoding once yields another Base64 string that needs decoding again. Or it may be encrypted, in which case decoding reveals ciphertext and there is nothing more to see without the key.
If the string was an image, the Base64 to image decoder will turn it back into a file with a preview. To encode in the other direction, use the Base64 encoder. Nothing you paste is transmitted, which matters given how often these strings contain credentials.
Decoding safely
Decoding a string is safe in itself. This page turns characters into text and does nothing with the result. What matters is what you do next. A decoded payload from an untrusted source is untrusted data: if it turns out to be HTML, do not paste it into a page without escaping it, and if it is JSON, validate it before feeding it to anything.
It is also worth remembering that a decoded token frequently contains credentials. Once decoded, that text is in your clipboard and possibly in your editor history. Treat it with the same care as the original secret rather than as inert output.