What happens if the input isn't valid Base64?

You get "Input is not valid Base64." instead of a partial decode or silently garbled text, because malformed input doesn't have a well-defined byte sequence to fall back to. That one message covers a few different cases: characters outside the Base64 alphabet, a length that leaves a single leftover character after whitespace is removed (which can never represent a full byte), and syntactically valid Base64 that decodes to bytes that aren't valid UTF-8, like an actual image or compressed file that got Base64-encoded instead of a string. Either way, the tool fails loudly instead of handing you corrupted or partial output, which is what you want right before trusting the result.

Does this handle Unicode text correctly?

Yes. The browser's native atob recovers the raw bytes first, then those bytes go through TextDecoder in fatal UTF-8 mode, so emoji, accented letters, CJK text, and anything else non-ASCII decode back to their exact original form. Decode "Y2Fmw6kg8J+OieaXpeacrOiqng==" and you get "café 🎉日本語" back, not a mangled or truncated approximation. Fatal mode is the key detail: instead of quietly substituting a replacement character (�) for any byte sequence that doesn't form valid UTF-8, the decoder throws right away, and this tool surfaces that as the same "not valid Base64" error. That's what makes it trustworthy for round-tripping real text rather than just returning something that looks plausible.

Is padding (=) required for the input to decode?

No, though plenty of people assume otherwise. The browser's atob implements the WHATWG "forgiving-base64 decode" algorithm, which treats trailing = padding as optional on input. "SGVsbG8" with no padding decodes to "Hello", same as the correctly padded "SGVsbG8h" decodes to "Hello!". What actually matters is the remainder when the un-padded length is divided by 4: 0, 2, or 3 all decode fine with or without padding, but a remainder of exactly 1 is always invalid, since a single leftover Base64 character can never represent a full byte, and no amount of padding fixes that. Padding still has to be well-formed if it's there at all, "Q=JD" or extra padding like "QUJD==" both fail, it just isn't mandatory. So if this tool succeeds on unpadded input, that's correct behavior, not a bug.

Can I decode URL-safe Base64 (with - and _) here?

Not directly. This tool decodes standard Base64, the RFC 4648 alphabet that uses + and /. If your input is the URL-safe variant instead (base64url, which swaps those for - and _ and is what JWT segments use), swap - back to + and _ back to / before pasting it in. Skip that step and atob rejects the input for containing invalid characters, since - and _ aren't part of the standard alphabet. This trips people up specifically with JWTs, whose header and payload segments are base64url by spec, not standard Base64, even though the two alphabets only differ by two characters.

Why does decoding fail on my string?

A handful of different causes all end up producing the same generic error. A character outside the Base64 alphabet (anything other than A-Z, a-z, 0-9, +, /, and =) fails immediately, usually stray punctuation or a URL-safe - or _ that needs swapping first. A length whose remainder after dividing by 4 is exactly 1 is invalid no matter what, since it can never represent a whole number of bytes. Padding that's present but malformed or misplaced, extra = characters, or one stuck in the middle of the string, fails too, even though missing padding on its own is fine. And the least obvious case: input that's perfectly valid Base64 syntax can still fail if the bytes it decodes to aren't valid UTF-8. "//4=" decodes to the two raw bytes 0xFF and 0xFE, which don't form a valid UTF-8 character, so it gets rejected even though the Base64 itself is well-formed. That last one usually means the original data was binary, an image or a compressed blob, and was never meant to be read as a string.

Is my Base64 data uploaded to a server?

No. Decoding happens entirely in your browser using the native atob and TextDecoder APIs, no backend call involved, so nothing you paste is transmitted, logged, or stored anywhere. Watch your browser's network panel while decoding and you'll see no outgoing request tied to the input. This matters more here than for most text operations, honestly, since the values people paste into a Base64 decoder are often credentials: a Basic Auth header, a JWT payload full of session claims, an API key pulled from a config file. Keeping it client-side means none of that leaves the tab it was pasted into.

How does this relate to the Base64 encode tool?

Exact inverses. Encode turns text into Base64, this one turns Base64 back into text, and chaining them should always return your original value unchanged. A genuinely useful debugging habit: decode a value you're unsure about here, then re-encode the result with the encode tool and check you get back the exact same Base64 string. A mismatch means the original wasn't standard Base64 to begin with, often because it used the URL-safe alphabet or had a stray character somewhere. The two tools stay separate instead of merging into one bidirectional widget because encoding and decoding fail so differently, encoding almost always succeeds on any text input, decoding can fail in several distinct ways, and keeping them apart keeps each tool's result unambiguous.

Does whitespace inside the input matter?

Not much. The tool trims leading and trailing whitespace before decoding, and the browser's atob implementation goes further, stripping ASCII whitespace (spaces, tabs, newlines) anywhere in the string as part of the forgiving-base64 algorithm, not just at the ends. So a Base64 string wrapped across multiple lines, like one copied from an email body or an old MIME attachment wrapping at 76 characters, decodes fine without being joined into one line first. What whitespace won't do is fix an otherwise-invalid string. Removing all whitespace from "SGVs bG8=" still leaves valid Base64 that decodes to "Hello", but if the underlying characters or length were already wrong, no amount of whitespace-stripping rescues it.

Base64 Decoder - Decode Base64 to Text Online

Overview

Introduction

Base64 shows up constantly in Authorization headers, JWT segments, and config files, but it's meant for machines, not eyes. This tool turns that block of letters and digits back into readable text instantly.

Decoding is the half of the round trip where mistakes actually cost you something. Paste a token into the wrong place and you might trust a plaintext-looking string without ever confirming it's what the server actually sent. This tool just decodes, locally, so you can inspect a Basic Auth value or a JWT payload without handing it to a third-party server, which matters a lot when the string itself carries credentials or session data.

What Is Base64 Decoder?

Base64 decoding reverses the standard binary-to-text encoding: each group of 4 Base64 characters maps back to 3 raw bytes, which are then interpreted as text.

The encoding is defined purely in terms of byte groups and a 64-character alphabet, so decoding doesn't know or care whether the original bytes were English prose, JSON, or raw binary. It just reconstructs the exact byte sequence that was encoded. What you get back is only 'readable' if the source was text to begin with, true for most credentials and tokens, not true for embedded images or files.

How Base64 Decoder Works

Your input passes through the browser's native atob to recover the raw bytes, then those bytes get decoded as UTF-8 via TextDecoder to reconstruct the original text. If the input isn't valid Base64, you get a clear error instead of a guess.

Decoding in fatal UTF-8 mode is deliberate. Rather than quietly substituting replacement characters for byte sequences that don't form valid UTF-8, the tool throws an error right away, which catches two problems at once: malformed Base64, and Base64 that legitimately encodes non-text binary data. Either way you get a clear failure instead of a string full of garbled placeholder characters.

When To Use Base64 Decoder

Reach for it to inspect a JWT's header or payload segment, check what's actually inside a Basic Auth Authorization value, or read a Base64-encoded string sitting in a config file or API response.

It's also handy for debugging any system that pushes data through Base64 as a transport convenience. Confirm that what went in is what comes back out, or verify that a value someone pasted into a ticket or log actually decodes to what they claim it says.

Often used alongside Base64 Encoder.

Features

Advantages

Runs entirely client-side, which matters when you're inspecting tokens that might carry sensitive data.
Reconstructs Unicode text correctly instead of showing mangled bytes.
Fails loudly on malformed input rather than quietly producing garbage.

Limitations

Expects standard Base64 (+ and /); URL-safe Base64 (- and _) needs a character swap first.
Can't recover meaningful text if the original bytes weren't UTF-8 to begin with, actual binary image data, for instance.

Base64 vs. Hexadecimal Encoding

Base64 vs. Hexadecimal Encoding
	Base64	Hexadecimal
Output size vs. input	About 133% of input	About 200% of input
Alphabet size	64 characters	16 characters (0-9, a-f)
Easy to read byte-by-byte	No	Yes, two characters per byte
Typical use	Tokens, binary blobs, embedding data in text	Hashes, checksums, color codes, byte dumps

Examples

Decoding a Basic Auth value

Input

dXNlcjpwYXNzd29yZA==

Output

user:password

Basic Auth headers carry credentials as Base64-encoded 'username:password', and this reveals the raw pair.

Decoding Unicode text with emoji

Input

Y2Fmw6kg8J+OieaXpeacrOiqng==

Output

café 🎉日本語

The recovered bytes get decoded as UTF-8, so the accented letter, the emoji, and the CJK characters all come back correctly instead of as mangled or truncated text.

Decoding unpadded Base64 successfully

Input

SGVsbG8

Output

Hello

No trailing = padding here at all, yet it decodes without error. The forgiving-base64 algorithm atob implements treats padding as optional, and only a length whose remainder after dividing by 4 is exactly 1 gets rejected.

Rejecting input with invalid characters

Input

SGVsbG8h@#!

Output

Input is not valid Base64.

@, #, and ! aren't part of the Base64 alphabet (A-Z, a-z, 0-9, +, /, =), so atob rejects the string outright instead of skipping over the characters it doesn't recognize.

Rejecting a single leftover character

Input

Output

Input is not valid Base64.

One Base64 character can encode at most 6 bits, never a full 8-bit byte. A string whose length leaves a remainder of 1 when divided by 4 has no valid decoding, no matter how it's padded.

Valid Base64 syntax that isn't valid text

Input

//4=

Output

Input is not valid Base64.

Well-formed Base64 that decodes cleanly to the two raw bytes 0xFF and 0xFE, but those bytes don't form valid UTF-8, so the fatal-mode TextDecoder step fails. Here the Base64 itself isn't the problem, the original data (likely binary, not text) is.

Best Practices & Notes

Best Practices

Never treat successful decoding as a security boundary. Base64 isn't encryption, and anyone can decode it.
When decoding a JWT segment, remember the header and payload are separate Base64url-encoded parts split by dots.
If decoding throws, check for a URL-safe alphabet or an invalid character before blaming padding, since missing padding alone isn't an error.
If text that should decode fine throws under fatal UTF-8 mode, consider that the original data may genuinely have been binary rather than corrupted Base64.
Don't manually strip line breaks from a long Base64 value copied out of an email or legacy system first. The decoder already tolerates embedded whitespace.

Developer Notes

This wraps the native atob call, which implements the WHATWG forgiving-base64 decode algorithm: padding optional, internal whitespace stripped, but a length remainder of 1 rejected. That's followed by a UTF-8 TextDecoder pass in fatal mode, so byte sequences that aren't valid UTF-8 come back as an error instead of getting silently replaced with the U+FFFD replacement character. Both failure modes, a rejected atob call and a failed fatal-mode decode, get caught by the same try/catch and surfaced as one generic "Input is not valid Base64." message. That keeps the error consistent, but it means the message alone can't tell you whether the string was syntactically invalid or syntactically valid Base64 that just isn't UTF-8 text. The input also gets trimmed of leading and trailing whitespace before hitting atob, mostly so an all-whitespace paste doesn't get treated as non-empty input.

Base64 Decoder Use Cases

Reading the payload segment of a JWT during debugging
Checking the decoded credentials behind a Basic Auth header
Decoding a Base64 value pulled from an API response or config file
Confirming whether a Base64-looking string found in a log or support ticket is genuinely valid before assuming it's corrupted
Inspecting the raw bytes behind the Base64 portion of a data URI

Common Mistakes

Trying to decode a URL-safe Base64 string without swapping - and _ back to + and / first.
Assuming a decode error means the string is corrupted or missing padding, when padding is actually optional and the real cause is often an invalid character or wrong length.
Not realizing a decode error can mean the original data was legitimate non-text binary rather than damaged Base64.
Manually appending = padding before decoding, when the unpadded original would already have decoded correctly.

Tips

JWTs have three Base64url segments separated by dots. Decode the header and payload separately, not the whole token at once.
Re-encode the decoded text with the Base64 encode tool to confirm you get back your original input exactly.
Not sure if padding is needed? Just try decoding the raw pasted value first. Most real-world Base64 already decodes fine unpadded.
A decode error right after a copy-paste often just means a character got dropped or altered in the copy. Worth re-copying the source before assuming the value itself is bad.

Base64 Decoder

Overview

Introduction

What Is Base64 Decoder?

How Base64 Decoder Works

When To Use Base64 Decoder

Features

Advantages

Limitations

Base64 vs. Hexadecimal Encoding

Examples

Decoding a Basic Auth value

Decoding Unicode text with emoji

Decoding unpadded Base64 successfully

Rejecting input with invalid characters

Rejecting a single leftover character

Valid Base64 syntax that isn't valid text

Best Practices & Notes

Best Practices

Developer Notes

Base64 Decoder Use Cases

Common Mistakes

Tips

References

Frequently Asked Questions