How to decode a Base64 string
- Paste the Base64 into the left Base64 box, the decoder runs live and the readable text lands in the right box.
- Don't worry about the variant: URL-safe strings (with
-and_) and strings missing their=padding are normalised for you before decoding. - If nothing sensible appears, check the status line, invalid characters or a truncated string are the usual culprits.
- Copy the decoded text, or press ⇄ Swap to re-encode it and confirm the round-trip matches.
How to recognise Base64 in the wild
Base64 tends to look like a long, dense run of mixed-case letters and digits with no spaces, often ending in one or two = signs, for instance aGVsbG8gd29ybGQ= decodes to the plain phrase hello world. You'll meet it as the value after Authorization: Basic (decode it and you'll usually see a user:password pair), as the two segments of a JWT sitting between the dots, as the giant blocks in raw email source that carry attachments, and as opaque binary values wedged into JSON, YAML, or Kubernetes Secrets. When you spot that pattern and want to know what it says, this is the tool.
Why a Base64 string fails to decode
Decoding is strict about its 64-character alphabet, so a handful of predictable problems account for nearly every failure. The most common is a copy that grabbed only a fragment of the string, or one that swept in surrounding whitespace and line breaks, this decoder trims whitespace for you, but a genuinely truncated string can't be recovered. Next is feeding it a whole JWT (three dot-separated parts) instead of a single segment: the dots aren't valid Base64, so decode one segment at a time. Finally, remember the golden rule, decoding is not decryption. If the "decoded" result is still gibberish, the original bytes were probably encrypted or compressed before being Base64-encoded, and no decoder can turn that back into plain text without the key.
Standard vs. URL-safe, you don't have to choose
There are two Base64 alphabets in common use and they differ in just two characters. The standard alphabet ends in + and /; the URL-safe variant swaps those for - and _ so the string survives inside URLs, filenames, and JWT segments. Some producers also drop the trailing = padding to save space. A decoder that only understood one alphabet would choke on the other, which is a frequent source of "it works in one tool but not another" confusion. This one normalises the input first, translating -_ back to +/ and restoring any missing padding, so you can paste either variant, from any source, without stopping to figure out which flavour you're holding.
Frequently asked questions
How do I decode a Base64 string?
Paste it into the input box and the decoded text appears instantly. URL-safe Base64 (using - and _) and strings with missing = padding are normalised automatically, so both variants just work.
Why does my Base64 string fail to decode?
Usually because the copy grabbed only a fragment, swept in whitespace or line breaks, or included characters outside the Base64 alphabet. This decoder trims whitespace and repairs padding, but a genuinely truncated string can't be reconstructed.
The output is still gibberish, what went wrong?
Decoding is not decryption. If clean Base64 decodes to garbage, the underlying bytes were probably encrypted, compressed, or a binary file format before they were encoded. Base64 only reverses the encoding step, not any transformation applied before it.
Can I decode a JWT with this?
Yes, but paste one segment at a time. A JWT is three parts joined by dots; feed the header or payload (the parts between the dots) to get JSON. The signature segment is raw binary and won't render as readable text. For a full breakdown use the JWT Decoder.
How do I go the other way, from text to Base64?
Use the Base64 Encode tool, or just click ⇄ Swap here to flip the decoded text back into the input and encode it.
Is the decoded data private?
Yes. Decoding happens entirely in your browser, tokens, credentials and payloads are never uploaded, logged, or sent to any server.