Base64 Decoder
Decode Base64 back to text or download it as the original file.
Base64 Decoder tool
This is binary, not text
Going the other way? Use the Base64 Encoder.
What this tool does
Paste a Base64 string and this decoder turns it back into what it was. If the bytes are text it shows them; if they are a PNG, a ZIP or a key file it says so and offers a download rather than filling the screen with replacement characters.
Both alphabets are accepted without you having to choose: the standard one with
+ and /, and the URL-safe one with - and
_. Padding may be present, absent or wrong. Line breaks, stray spaces and a
leading data:image/png;base64, are all stripped before decoding.
Common uses
-
Reading a Kubernetes secret.
kubectl get secret -o yamlreturns every value Base64-encoded, and the interesting part is usually one field. - Recovering the image behind a data URI you found in a stylesheet or an email's HTML source.
-
Checking what a Basic auth header actually contains — it decodes to
username:passwordwith no hashing whatsoever. - Unpacking a Base64 field from a log line or a webhook payload to see what a system sent.
- Opening a certificate body to confirm it is the key you think it is.
A short example
This input:
SGVsbG8sIHdvcmxkIQ== decodes to:
Hello, world!
And a string in the URL-safe alphabet decodes identically —
aGVsbG8-d29ybGQ_ and aGVsbG8+d29ybGQ/ are the same nine bytes.
Why a string fails to decode
Four problems account for nearly every failure, and this tool names whichever one it finds rather than reporting a generic error:
- A truncated string. If the length leaves a remainder of 1 when divided by 4, no sequence of bytes could have produced it — a character was lost in a copy.
- A character that is not in either alphabet. A space that should have been a
+is the classic case: passing Base64 through an unencoded query parameter turns every+into a space. - Padding in the middle, which means two strings were concatenated.
- Both alphabets at once, which usually means a find-and-replace ran over only part of the value.
Worth knowing
Base64 hides nothing. A token, a password or a key pasted here was never protected by the encoding — anyone who intercepted it could read it just as easily. Treat a decoded credential as compromised if it travelled anywhere untrusted.
One subtlety about Latin-1 mode: it is not a fallback for broken UTF-8, it is a different interpretation. Every byte becomes exactly one character, so bytes that are meaningless as UTF-8 still produce output — output that is only correct if the data really was Latin-1.
Frequently asked questions
How can I tell what a blob is before I decode it?
The opening characters give it away, because the leading bytes of each format are fixed. iVBORw0KGgo is a PNG, /9j/ a JPEG, JVBERi0 a PDF, H4sI gzip, and UEsDB a ZIP — which also means a .docx, .xlsx or .jar, since those are ZIP containers. eyJ decodes to an opening brace and quote, so it is JSON.
Why does my Kubernetes secret decode with an invisible newline on the end?
Because it was built with echo instead of echo -n, so a trailing 0a byte was encoded with the value and the application receives a password one character longer than the one you set. The symptom is authentication that fails everywhere while the secret looks correct in the manifest. Using kubectl create secret generic --from-literal keeps the shell out of it entirely.
Can I decode a whole JWT here?
One segment at a time. A JWT is three Base64url strings joined by dots, so the value as a whole is not valid Base64 — paste the middle segment to read the claims. The third segment is a raw signature and decodes to binary rather than text. The JWT decoder splits and labels all three, and checks the signature when you give it the key.