Base64 Decode

Decode Base64 back to text in your browser. Handles URL-safe characters, missing padding and line-wrapped input, with correct UTF-8 output.

🌐 Español

🔒 Private by design: your text is processed locally in your browser and never uploaded to any server.

Written and maintained by Last updated

The result is text, and only text

Base64 can carry any bytes at all, but this page only finishes the job when those bytes turn out to be readable text. After the encoded string is converted back into a byte sequence, the bytes are handed to a strict UTF-8 decoder, and a sequence that is not valid UTF-8 makes the run fail instead of returning something garbled.

That is a deliberate boundary rather than a limitation to apologise for. It means an accented name, an emoji or a line of Japanese in a payload comes back exactly as it was written, because the bytes are reassembled with the same UTF-8 rules that produced them. It also means a Base64 blob that is really a PNG, a ZIP or a font will not decode here, and you want it to fail loudly in that case rather than dumping several megabytes of unprintable characters into a text box.

Pasting a value and reading it back

  1. Paste the Base64 into the box above. Standard or URL-safe, padded or not, on one line or wrapped across fifty, all work.
  2. Click Base64 Decode. The button stays disabled while the box is empty.
  3. Read the decoded text in the panel that replaces the form, and take it with Copy to clipboard.
  4. Click Process another to clear the box and decode something else. The form does not stay on screen alongside the result, so this is the way back.

Whitespace, hyphens and underscores are handled before anything else

Three normalisations run before the decoder ever sees your input, and between them they cover the great majority of pastes that would otherwise fail.

All whitespace goes first, everywhere in the string, not just at the ends. Line-wrapped blocks, indented blocks and blocks with a stray space in the middle all collapse to one continuous run of characters.

Then the URL-safe alphabet is translated back. Standard Base64 uses + and / as its last two characters, but neither survives a URL intact, so a variant swaps them for - and _. JWT segments use it, signed URL parameters use it, and filenames use it. Every - becomes + and every _ becomes /, unconditionally, which is safe precisely because standard Base64 can never legitimately contain either one.

Padding arithmetic, and the length that can never be valid

Base64 encodes three bytes into four characters, so a valid encoded length is always a multiple of four, and = characters are appended to reach it. Since so many systems drop that padding, the padding here is recalculated rather than assumed:

That last case is the useful one for debugging. If your paste is refused on length, you are not looking at a padding problem you can fix by adding equals signs; you are looking at a string that lost characters somewhere, usually to a truncated copy, a wrapped terminal, or a value that was cut short in a log.

The prefixes you have to strip yourself

Nothing on this page tries to be clever about what surrounds your Base64, so a few very common wrappers have to come off before pasting:

In practice this short list accounts for most of the pastes that look like Base64 and refuse to behave, and checking it takes less time than reading an error would.

The same decoder the JWT page calls

The function behind this page is not exclusive to it. The site’s JWT Decoder imports this exact decoder and runs it on the header and payload segments of a token, which is a reasonable proof that the URL-safe handling and the padding arithmetic described above hold up against real tokens rather than against tidy examples. It also means there is no reason to decode a JWT segment by segment here: paste the whole token there and get the header, the payload and the expiry status in one go.

Coming the other way, Base64 Encode is the mirror of this page. It always writes the standard alphabet with padding, so anything it produces decodes here unchanged, and anything URL-safe you bring from elsewhere is translated on arrival.

See it in action

Screenshot of the Base64 Decode tool with the sample input “RXZlcnl0aGluZyBydW5zIGluIHlvdXIgYnJvd3Nlci4=”
Base64 Decode mid-process: the sample input “RXZlcnl0aGluZyBydW5zIGluIHlvdXIgYnJvd3Nlci4=”.
Screenshot of the Base64 Decode result screen showing the generated output “Everything runs in your browser.”
The finished result: the generated output “Everything runs in your browser.”. The download link is a local blob URL — the file never leaves your device.

Frequently asked questions

I pasted a certificate and it refused to decode. What went wrong?

Almost certainly the BEGIN and END lines. A PEM file surrounds its Base64 body with lines of hyphens, and hyphen is a meaningful character here because it belongs to the URL-safe alphabet, so every one of those hyphens is rewritten to a plus before decoding is attempted. The header turns into nonsense that no decoder will accept. Deleting the BEGIN and END lines and pasting only the block between them gets the Base64 layer to decode, but a certificate body is DER, which is binary rather than text, so this page then refuses it for exactly the same reason it refuses a PNG. Decoding a certificate needs a certificate decoder, not this page.

Do I need to join line-wrapped Base64 into one line first?

No. Every space, tab, carriage return and newline is removed before anything else happens, so a block wrapped at 64 or 76 characters per line decodes exactly as if it had arrived as one continuous string. This also means an accidental space in the middle of a token is harmless, which is a small mercy when copying values out of a terminal that has soft-wrapped them.

Can I decode a Base64 image or a PDF here and download the file?

No. After the Base64 is turned back into bytes, those bytes are decoded as UTF-8 text in strict mode, and a PNG or a PDF is not valid UTF-8, so the run fails rather than producing a corrupted mess. There is also no download on this page, only a text result you can copy. For an image specifically, the Image to Base64 tool has a reverse box that takes either a full data URI or a bare Base64 payload and shows you the picture it decodes to.

My token has no equals signs at the end. Is it truncated?

Probably not. Padding is recomputed from the length rather than trusted, so a string whose length is two short of a multiple of four gets two equals signs added, one short gets one, and a length that already divides by four gets none. Dropping the padding is normal practice in JWTs and URL parameters, where the length is known anyway. The one length that genuinely cannot be valid Base64 is one character past a multiple of four, and that does signal a truncated copy.

When a decode fails, where do I find out why?

On the page you get a single generic sentence asking you to check the input and try again, which is the same message every failure produces. The specific reason, whether the alphabet was wrong, the length was impossible, or the bytes were not valid UTF-8, is written to the browser console instead. Opening developer tools and looking at the console before the second attempt usually saves a round of guessing.

If a JWT payload decodes cleanly here, does that mean the token is valid?

No, and this is worth being clear about. Decoding proves only that the segment was well-formed Base64 holding readable text. It says nothing about whether the signature matches, whether the token has expired, or whether it was issued by anyone you trust. Anybody can craft a JWT whose payload decodes beautifully. The dedicated JWT Decoder on this site splits a whole token for you and states outright that the signature segment is shown but not verified, which is the honest position for any browser-side tool without the signing key.

Related tools