How to Decode Base64 Online (and What the Result Means)

You have a string of seemingly random letters and numbers — maybe ending in one or two equals signs — and you need to know what it says. That is almost certainly Base64, and decoding it reveals the original text or data. Here is how to decode Base64, what the result tells you, and the two variants that cause decoders to fail.

How to decode it

Decoding Base64 is instant: paste the encoded string into a decoder, and it converts it back to the original text. Base64 is fully reversible — it is an encoding, not encryption, so no key is needed and anyone can decode any Base64 string in a second. If the result is readable text, you have your answer. If the result looks like binary garbage, the original data was not text — it might have been an image, a file, or encrypted data that was then Base64-encoded, in which case the decoded bytes are not meant to be read as text.

Why you'd need to decode Base64

Base64 shows up in many places you might need to inspect. The header and payload of a JWT authentication token are Base64-encoded, and decoding them reveals the claims inside. HTTP Basic Auth credentials are Base64 in the Authorization header. Data URLs embed Base64-encoded images. Email source shows Base64-encoded attachments. Config files and API responses sometimes carry Base64 data. When you are debugging any of these, decoding lets you see what is actually there rather than a wall of encoded characters.

The Unicode gotcha

If your decoded text comes out garbled where there should be accents or non-English characters, the issue is Unicode handling. Base64 encodes bytes, and text has to be turned into bytes via an encoding like UTF-8 first. A decoder that assumes plain ASCII will mangle accented letters, emoji, and non-Latin scripts. A proper decoder interprets the bytes as UTF-8, so "café" and "こんにちは" decode correctly. If you see mojibake — garbled characters — the encoder or decoder mishandled the Unicode step.

The URL-safe variant

If a decoder rejects your string or produces wrong output, it might be Base64url — the URL-safe variant. Standard Base64 uses + and / characters, but those cause problems in URLs, so Base64url replaces + with - and / with _, and often drops the = padding. JWTs use this variant. A strict standard decoder may choke on the - and _ or on missing padding. The fix is to convert - back to +, _ back to /, and restore the padding before decoding — or use a tool that handles both variants automatically.

Remember: decoding is not decryption

One important point. Decoding Base64 reveals whatever was encoded, with no key required — which means Base64 provides no security whatsoever. If you can decode it, so can anyone else. This is why you should never store passwords or secrets as Base64 thinking they are hidden; they are trivially readable. Decoding a JWT payload shows you the claims but does not verify the token — that requires checking the signature with a secret key, a separate step. Base64 is about representation, never protection.