About Base64 Decode

This tool reverses Base64 (RFC 4648): it maps each character back to its 6-bit value, reassembles the bytes, and interprets them as UTF-8 text. Decoding is the step where problems surface — a string that was encoded with a different variant, wrapped across lines, truncated in a log, or double-encoded will fail or produce garbage here, and the error tells you which of those happened.

Everything runs in your browser. That makes it safe to decode things you should never paste into random websites' servers: JWT segments, Basic auth headers, session cookies, webhook payloads.

How to use Base64 Decode

  1. Paste the Base64 string in the input area.
  2. Click "Convert" to decode to plain text.
  3. Copy or download the decoded result.

Example

Input

SGVsbG8sIFdvcmxkIQ==

Output

Hello, World!

How decoding works and why length matters

Base64 maps 4 characters back to 3 bytes, so a valid Base64 string (with padding) always has a length that is a multiple of 4. A decoder checks three things: every character belongs to the alphabet (A–Z, a–z, 0–9, +, /, plus = padding at the end), padding appears only at the end, and the length is consistent. Violate any of these and you get an InvalidCharacterError-style failure.

One length is mathematically impossible: a block of 1 character (or length ≡ 1 mod 4). If your string has such a length, a character was lost in transit — commonly a trailing = stripped by a form or a truncating logger.

Decoding text vs decoding binary

After the bytes are recovered, this tool decodes them as UTF-8 text, which is what you want for JSON payloads, JWT segments, and configuration values. If the original data was binary — an image, a PDF, a protobuf message — the bytes are not text, and rendering them as text produces gibberish with replacement characters (�). The decode itself succeeded; the data is just not text. Recognize binary by magic bytes at the start: ‰PNG, %PDF, PK (zip)…

Reading real-world Base64: three quick recipes

  • JWT inspection: split the token on dots; the first two segments are base64url-encoded JSON. Convert - to + and _ to /, then decode. (Or use the JWT Decoder tool, which does all of it.)
  • Basic auth: the part after 'Basic ' decodes to user:password. Useful for confirming which credentials a client actually sent.
  • data: URLs: everything after ;base64, is the payload. Decode to check what an inline resource really contains.

Common errors and how to fix them

InvalidCharacterError / "The string to be decoded is not correctly encoded"

Cause: The string contains characters outside the standard alphabet — most often - and _ from base64url, or accidental whitespace/newlines.

Fix: Replace - with + and _ with /, strip all whitespace, and re-pad with = until the length is a multiple of 4.

"Invalid length" or decode fails near the end

Cause: Padding was stripped (forms and URL parsers often eat trailing =), or the string was truncated.

Fix: Append = or == so the length is a multiple of 4. If that still fails, the value was cut off — recover the full string from the source.

Output is unreadable symbols with � characters

Cause: The decoded bytes are not UTF-8 text — either binary data or text in a legacy encoding (Latin-1, Windows-874, TIS-620).

Fix: If binary, check magic bytes to identify the format instead of reading it as text. If legacy text, decode the bytes with the right charset in a script.

Decoded result is still Base64

Cause: The value was encoded twice — common when middleware encodes an already-encoded payload.

Fix: Decode again. If you control the producer, remove the redundant encoding step; double encoding wastes ~78% size overhead.

Decoded JSON has escaped quotes like {\"a\":1}

Cause: The original data was a JSON string containing JSON (double-serialized), not Base64's fault.

Fix: Run the result through the JSON Unescape tool, then parse.

Tips and best practices

  • A quick sanity check before decoding: valid Base64 length is a multiple of 4 (after stripping whitespace), and = appears only at the very end.
  • If a payload decodes to gibberish, try the base64url→standard character swap first — it fixes the majority of 'invalid character' failures.
  • PEM files (certificates, keys) are Base64 between the BEGIN/END lines, but the decoded content is DER binary — meaningful in a parser, not as text.
  • Never paste production secrets into online tools that process data server-side. This one doesn't — but the habit of checking is worth keeping.

Frequently asked questions

Why does decoding fail with - or _ in the input?
Those characters belong to base64url, the URL-safe variant used by JWTs and OAuth. Swap - for + and _ for /, add padding to a multiple of 4, and standard decoding succeeds.
Can I decode a JWT here?
You can decode each segment (they are base64url), but the dedicated JWT Decoder tool splits the token, decodes header and payload, and pretty-prints the claims in one step.
The output looks like random symbols — is the tool broken?
The decode worked; the data just isn't text. Images, archives, and other binary formats decode to raw bytes that don't render as readable characters. Check the first bytes (‰PNG, %PDF, PK) to identify the format.
Does whitespace in the input matter?
Line breaks are common in MIME and PEM formatted Base64. This tool tolerates surrounding whitespace, but strict decoders in code may not — strip whitespace before decoding programmatically.
Is decoded data private?
Yes. Decoding runs entirely in your browser, so tokens and credentials never leave your machine.

Embed this tool

Add Base64 Decode to your own site, blog post, or internal docs — free, no signup. The widget runs entirely in your visitors' browsers, same as it does here.

Related tools