Does the decoder accept URL-safe Base64?

Yes. It normalizes - and _ back to + and / and restores missing padding before decoding, so you can paste tokens and values that use the URL-safe alphabet without any manual cleanup.

Why does my decoded text look like gibberish?

The input probably was not text to begin with - for example, a Base64-encoded image or compressed blob. Base64 only reverses the encoding; it cannot turn arbitrary binary data into readable text.

What if the Base64 is missing padding?

The tool re-adds the trailing = characters automatically. Missing padding is common in URL-safe tokens, so valid input decodes correctly even when the = signs were stripped.

Can I decode the payload of a JWT here?

You can decode any single Base64URL segment, but for tokens use the dedicated JWT Decoder - it splits the three parts, decodes each, and formats the JSON claims for you. Note that neither tool verifies the signature.

Is my input sent to a server?

No. Decoding is performed locally with the browser's atob and TextDecoder APIs. Nothing you paste is transmitted, logged, or stored anywhere.

Base64 Decode

Stable

Decode Base64 back to readable text, including URL-safe input.

Everything is processed locally in your browser

About Base64 Decode

Paste any Base64 string and get the original text back instantly. The decoder accepts both the standard and URL-safe alphabets, tolerates missing padding and stray whitespace, and interprets the bytes as UTF-8 so accented characters and emoji come through intact. All decoding happens in your browser.

Features

Decode standard and URL-safe Base64 without switching modes
Tolerant parsing: ignores line breaks and fixes missing = padding
UTF-8 aware output so multi-byte text decodes correctly
Optional data: URL stripping to decode the payload of an inline asset
Clear, inline errors for invalid or truncated Base64
Live decoding as you type, with one-click copy of the result

How to use Base64 Decode

1
Paste your Base64
Drop in a standard or URL-safe Base64 string. Whitespace, newlines, and a leading data: URL prefix are handled automatically.
2
Read the decoded text
The original text appears immediately, decoded as UTF-8. If the input is not valid Base64, a clear error explains why.
3
Copy the result
Copy the decoded output to reuse it elsewhere - in a request body, a config value, or your editor.

Examples

Decode to plain text

Standard Base64 decoded back to the original UTF-8 string.

Input

SGVsbG8sIFdvcmxkIQ==

Output

Hello, World!

How Base64 decoding works

Recognising Base64, and telling it apart from other encodings

Base64 has a recognisable signature. Its length is a multiple of four when padded, it draws only from `A-Za-z0-9+/=`, any `=` characters appear only at the very end, and it has no spaces or line breaks except in the MIME variant. If a string is long, dense, alphanumeric and mixed-case, Base64 is the first thing to try.

Two look-alikes are worth ruling out. Hexadecimal uses only `0-9a-f` and its length is a multiple of two, so a lowercase string with no letters past `f` is hex rather than Base64 - a 64-character one is very likely a SHA-256 digest. Percent-encoded text contains `%` followed by two hex digits and stays mostly readable, which Base64 never does.

The strongest signal for JWTs is the shape: three chunks separated by dots, using `-` and `_` rather than `+` and `/`, with no padding. Decode the first chunk and you should find JSON beginning `{"alg":`.

Decoded output is bytes, and not always text

Decoding always produces bytes. Whether those bytes are meaningful as text depends entirely on what was encoded, and there is no way to tell from the Base64 itself. A PNG, a PDF, a protobuf message and a UTF-8 string all encode to indistinguishable-looking Base64.

So if the decoded result is a mess of replacement characters, the likely explanation is that it was never text. The magic bytes at the start are the quickest identification: `%PDF` for a PDF, `PK` for anything zip-based including `.docx` and `.xlsx`, `\x89PNG` for a PNG, `GIF8` for a GIF, and `\xff\xd8\xff` for a JPEG.

When the bytes are text, the encoding still has to be right. UTF-8 is the safe assumption today, but a decoder that assumes Latin-1 will render multi-byte characters as pairs of accented symbols - the familiar `Ã©` where `é` belongs. That is a text-decoding error downstream of a perfectly correct Base64 decode.

Why a decode fails

Whitespace is the most frequent cause. Base64 copied from an email header, a PEM certificate or a wrapped log line contains line breaks, and a strict decoder rejects them. MIME actually mandates breaks every 76 characters, so this is correct input that still needs cleaning before a strict decoder will accept it.

Variant mismatch is the second. Feeding URL-safe Base64 containing `-` and `_` to a standard decoder fails, because neither character is in the standard alphabet. JWT segments hit this constantly.

Truncation is the third and the most annoying, because it can partly succeed. If a value was cut off - a log field with a length cap is the usual culprit - the decode either fails on the length check or returns a truncated result that looks plausible. When decoded JSON is missing its closing brace, suspect truncation upstream rather than a decoding problem.

Reference

Identifying an encoded string

Looks like	Probably	Test
Mixed case, +/=, length ÷ 4	Base64	Decode it
Only 0-9a-f, length ÷ 2	Hexadecimal	64 chars suggests SHA-256
Mostly readable with %XX	Percent-encoded	Use the URL Decode tool
Three dot-separated chunks	JWT	Use the JWT Decoder
Starts JVBERi0	A PDF	Decode to bytes and save as .pdf
Starts iVBORw0KGgo	A PNG	Decode to bytes and save as .png
Starts UEsDBB	A zip, .docx or .xlsx	Save and open with an archiver
Starts eyJ	JSON beginning {"	A JWT segment or encoded JSON

Which tool should you use?

These tasks overlap. Here is how to pick the right one for what you are actually doing.

You have an opaque Base64 string from a log or a header: Decode it here. If the result is binary, check the magic bytes to identify the file type.
The string has three parts separated by dots: That is a JWT. The JWT Decoder splits and decodes all three segments and formats the claims.
The text is mostly readable but full of %20 and %3A: That is percent-encoding, not Base64. Use the URL Decode tool.
You are encoding rather than decoding: The Base64 Encode tool handles that direction, including the URL-safe variant.

Use cases

Inspecting Base64-encoded payloads found in logs or API responses
Reading the contents of a data: URL
Decoding the header or payload segment of a JWT by hand
Recovering config values that were stored in Base64
Debugging encoding issues where text arrives garbled

Troubleshooting common errors

"Invalid character" on a string from an email or a certificate

Why: Line breaks. MIME Base64 wraps at 76 characters, and strict decoders reject the newlines.

Fix: Strip all whitespace before decoding. For PEM files, also remove the BEGIN and END header lines.

A JWT segment will not decode

Why: JWTs use the URL-safe alphabet and omit padding, so `-` and `_` are not in the standard alphabet.

Fix: Switch to URL-safe decoding, or use the JWT Decoder which handles it automatically.

The output is unreadable symbols

Why: The original data was binary, not text - an image, a PDF, or a compressed archive.

Fix: Check the first few bytes against the table above and save the output with the matching file extension.

Why: The bytes were decoded as Latin-1 when they are UTF-8.

Fix: Decode as UTF-8. The Base64 step was correct; the text interpretation was not.

The decoded JSON is cut off mid-way

Why: The Base64 itself was truncated before you received it, usually by a length-capped log or database field.

Fix: Retrieve the full value from the source. Nothing at the decoding stage can reconstruct missing input.

Limitations

What this tool deliberately does not do, so you know when to reach for something else.

Decoding produces bytes, and there is no way to know from the Base64 whether they represent text.
Truncated input can decode partially, producing plausible but incomplete output.
Standard and URL-safe variants require the matching decoder.
Base64 offers no integrity check, so corruption is not detected.
Very large inputs are limited by browser memory.

Frequently asked questions

Base64 Encode

Encode text or files to Base64, with an optional URL-safe variant.

URL Decoder

Decode percent-encoded URL strings back to plain, readable text.

JWT Decoder

Decode a JWT to inspect its header, payload, and claims instantly.

Learn more

How to Decode Base64 Back to Readable TextBase64 encoding turns bytes into safe text, and decoding undoes that step. This guide covers how decoding works, why URL-safe tokens need extra care, and how to recover the original text without uploading it anywhere.