Base64 Decoder
Decode Base64 strings back to plain text.
About Base64 Decoder
Base64 shows up wherever bytes have to travel through something that only handles text: an Authorization: Basic header, a Kubernetes Secret, a certificate pasted into a config file, a data: URI in a stylesheet. Paste the string above and this page reverses the transformation, four characters at a time, back into the original three bytes.
Two decoding steps, and why the second one can fail
Decoding happens in two stages. First the characters are mapped back to bytes, which either succeeds or reports Invalid Base64 string. Then those bytes are interpreted as UTF-8 text so that accented letters, CJK characters and emoji come out whole. The second stage is the one that can be wrong even when nothing errored: if the payload was a PNG, a ZIP or a protobuf message, the bytes are perfectly valid but they are not text, and what you see is the tool rendering them literally.
Reading the failure message
Only two things trigger the red error box. One is a character outside the standard alphabet — most often a hyphen or underscore from the URL-safe variant, occasionally a stray quote copied along with the value from JSON. The other is a length that no valid Base64 string can have, which means the value was cut off in transit. Whitespace, newlines and missing padding are all handled silently, so they are never the cause.
What decoding does and does not prove
A string that decodes cleanly has told you nothing about who produced it. Base64 is an encoding, not a signature and not encryption, and a Kubernetes Secret is exactly as readable as its data field suggests. Treat any credential recovered here as public the moment it appeared on screen.
When another tool fits better
For a JSON Web Token, use the JWT Decoder: it handles the URL-safe alphabet, splits the three segments for you and pretty-prints the claims. For percent-encoded text such as %20 and %3D, that is URL encoding rather than Base64 — the URL Decoder is the right tool. And when the decoded output turns out to be JSON, the JSON Formatter will indent it into something readable.
Whitespace And Padding Tolerant
Base64 wrapped across many lines, or missing its trailing equals signs, decodes without any cleanup — paste straight from a PEM block, an email header or a log file.
Strict UTF-8, With A Fallback
Text is decoded as UTF-8 so accents and emoji survive intact. When the bytes are not valid UTF-8 the tool shows them raw instead of failing, which is how you spot that a value was really a file.
One Browser API Call
Decoding uses the platform’s own atob, so there is no upload, no queue and no history. Closing the tab is all the cleanup there is.
Frequently Asked Questions
Why does my string fail with hyphens and underscores in it?
Because that is base64url, a different alphabet. It swaps plus for hyphen and slash for underscore so the value is safe inside URLs and filenames, and it usually drops the trailing equals signs too. This box expects the standard alphabet and rejects the substitutes outright. Replace every hyphen with a plus and every underscore with a slash and it will decode. If the value came from a JSON Web Token, the JWT Decoder does that translation for you and parses the claims as well.
Do line breaks or missing padding matter?
Neither breaks anything here. Base64 copied out of an email header, a PEM certificate or a wrapped log line arrives split across many 64- or 76-column rows, and the browser's decoder ignores all whitespace before it starts. Absent equals signs are tolerated as well. The one length that genuinely cannot be decoded is a string whose character count leaves a remainder of one when divided by four — that is a truncated value, not a padding problem, and the missing characters cannot be reconstructed.
Why is the output full of question marks and boxes?
The bytes decoded correctly but they were never text. The tool first attempts a strict UTF-8 decode; when that fails it falls back to showing the raw bytes one character at a time, which is what produces the garbage. A result starting with PNG, PK or %PDF is a real file that happens to have been Base64-wrapped, and reading it in a text box will not help — it needs to be written back out as a binary file.
Does decoding tell me whether the data was tampered with?
No. Base64 carries no checksum, no signature and no key, so a modified string simply decodes to different bytes without complaint. The only inputs that raise an error are ones containing characters outside the alphabet or a length that cannot be valid. If integrity matters, compare a digest of the decoded content using the Hash Generator against a digest you trust.
Is it safe to paste a token or credential in here?
Nothing you paste leaves this tab — decoding is a single browser API call with no network step, which you can confirm in the Network panel of DevTools. The real risks are local rather than remote: the value sits in your clipboard, in the page until you navigate away, and in a screen recording or shoulder-surfer's view. For a live production secret, decode it on your own machine instead.
Can I decode more than one string at a time?
No. Whitespace is stripped before decoding, so several strings on separate lines are treated as one long value. If they still carry their trailing equals signs, the padding ends up in the middle of that value and you get the red Invalid Base64 string error; if the padding was already absent, the strings silently merge and decode to garbage. Either way, decode them one at a time.