Base64 decoder
What Is Base64 Decoding?
Base64 decoding is the reverse of Base64 encoding: it takes a Base64-encoded string — a block of seemingly random letters, digits, and symbols — and converts it back into the original text or data. If encoding is packing binary into a text-safe envelope, decoding is opening that envelope. Paste in something like "SGVsbG8sIHdvcmxkIQ==" and get back "Hello, world!" instantly.
You encounter Base64-encoded data constantly without realizing it. Every email attachment travels as Base64 inside the message. JSON Web Tokens (JWTs) carry Base64url-encoded headers and payloads between the dots. Images embedded in web pages via data URIs are Base64 blocks. API responses sometimes wrap binary content as encoded strings. HTTP Basic auth headers contain Base64 credentials. When any of these need inspection — debugging a broken attachment, reading a JWT's claims, checking what an API actually returned — decoding is the first step.
Decoding is deterministic and immediate: the same input always produces the same output, with no key or password involved. That fact doubles as a security lesson — if you can decode something in one click with no secret, so can anyone else, which is why Base64 must never be mistaken for encryption. Our Base64 encoder performs the forward transformation; this page handles the reverse. Developers often combine both with our URL decoder when untangling doubly-encoded web data, and our JSON formatter when the decoded output turns out to be JSON.
Like all WebTaskTools utilities, decoding happens instantly and your input is never stored — paste freely, even when inspecting tokens from your own development environment. The examples on this page use short strings, but the same one-click process handles the multi-kilobyte blobs that real APIs and email attachments produce.
How to Use the Base64 Decoder
- Paste the Base64 string. Copy the encoded text — from an email source view, a JWT, an API response, or a data URI — and paste it into the input box.
- Strip any prefix. If you copied a data URI like
data:image/png;base64,iVBOR…, remove everything up to and including the comma; only the part after the comma is Base64. - Choose the alphabet if needed. Standard Base64 uses + and /; URL-safe Base64 uses - and _. Most decoders auto-detect, but if yours doesn't, select the matching variant.
- Click Decode. The original text appears instantly in the output box.
- Interpret the result. If the output is readable text, you're done. If it's JSON, paste it into a JSON formatter; if it's still binary gibberish, the original data was a file, not text.
- Copy or clear. Copy the decoded result for your debugging notes, then clear the boxes for the next string.
Recognizing Base64 in the Wild
Base64 has a distinctive look once you know the tells. The string uses only A–Z, a–z, 0–9, +, /, and trailing = signs (or - and _ in URL-safe mode). Its length is always a multiple of 4. It often ends with one or two "=" padding characters. And it has high visual entropy — no recognizable words, roughly uniform character distribution.
| What you see | What it probably is | How to decode it |
|---|---|---|
| Three dot-separated segments (xxxxx.yyyyy.zzzzz) | JWT | Decode the first two segments as URL-safe Base64 → JSON header and payload |
| data:image/png;base64,iVBOR… | Data URI image | Strip the prefix up to the comma, decode the rest → binary image |
| Long block in email source between MIME boundaries | Email attachment | Decode → original file bytes |
| "Basic dXNlcjpwYXNz" HTTP header | Basic auth credentials | Decode → "user:pass" (username, colon, password) |
| -----BEGIN …----- with Base64 body | PEM certificate/key | Decode the body → DER binary (view with openssl, not as text) |
| Random-looking string in a JSON field | API-embedded binary | Decode → file bytes or nested text |
Key Features
- Instant decoding — paste and get the original text immediately.
- Standard and URL-safe alphabets — handles both +/ and -/_ variants, including JWT segments.
- Padding-tolerant — accepts input with or without trailing = padding.
- Whitespace-tolerant — ignores line breaks and spaces, so MIME-wrapped output (76 chars/line) decodes cleanly.
- UTF-8 output — decoded bytes are interpreted as UTF-8, so emoji and non-English text round-trip correctly.
- Clear error messages — invalid characters are flagged instead of silently producing garbage.
- Not stored — input is processed instantly and never stored, logged, or retained.
- Free and unlimited — decode as many strings as you need.
Reading a JWT by Decoding It
Decoding a JWT is the single most common real-world use of Base64 decoding, so it's worth walking through. A JWT looks like eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c — three Base64url segments separated by dots. Paste the first segment into the decoder (as URL-safe Base64) and you get {"alg":"HS256","typ":"JWT"}: the signing algorithm. Decode the second segment: {"sub":"1234567890","name":"John Doe","iat":1516239022} — the claims: subject, name, issued-at timestamp.
Two critical insights fall out of this exercise. First, the payload is merely encoded, not encrypted — anyone holding the token can read every claim, so never put passwords, SSNs, or other secrets in a JWT payload. Second, the third segment is the cryptographic signature; decoding it yields raw binary gibberish, because it's not meant to be read — it's meant to be verified with the secret key. A token with a readable payload but an invalid signature must be rejected, no matter how legitimate the claims look. If you're debugging authentication issues, decoding the payload tells you what the token claims; verifying the signature tells you whether to believe it.
Use Cases
Backend developers debugging APIs
The problem: An API returns a JSON field containing an opaque Base64 blob, and the integration is failing. Is the blob the expected file? Corrupted data? An error message someone encoded by mistake?
How this tool helps: Decode the blob in seconds. Readable text or JSON means it's a nested payload — format it and inspect it. Binary gibberish means it's file bytes, and you can check the size and magic bytes against expectations.
Frontend developers inspecting tokens
The problem: Authentication is misbehaving — the app sends a JWT, the server rejects it, and nobody knows whether the token contains the wrong user ID, an expired timestamp, or a malformed claim.
How this tool helps: Decode the payload segment to read the claims directly: check the user ID, the expiry (exp), and the issuer. Half of all JWT bugs are visible the moment you read the payload.
Email administrators
The problem: A user reports a corrupted attachment. The mail logs show the message arrived intact, so the corruption happened during encoding, transport, or decoding — but where?
How this tool helps: Extract the MIME attachment block from the raw message source and decode it here. If it decodes cleanly, the encoding is fine and the problem is downstream; if it fails, you've isolated the fault to the encoded body itself.
Security analysts
The problem: A log line, phishing email, or suspicious script contains an encoded blob. Attackers routinely Base64-encode payloads to dodge naive string-matching defenses.
How this tool helps: Decode the blob to reveal the underlying command, URL, or script. (Do this in a safe environment — decoded output may itself be malicious, so don't execute it, just read it.)
Students and self-learners
The problem: Encoding concepts stay abstract until you see them work on real data.
How this tool helps: Pair it with the encoder: encode any text, then decode it back and confirm you get the exact original. Break things deliberately — remove padding, change one character — and observe how decoding fails. Hands-on failure teaches the format faster than any diagram.
Data engineers
The problem: A pipeline ingests records with Base64-encoded fields, and a downstream consumer reports garbled values. Is the source encoding wrong, or is the consumer decoding wrong?
How this tool helps: Decode a sample record independently here. If it decodes cleanly, the source is fine and the consumer's decoder is suspect; if it fails here too, the data was bad at the source.
Double Encoding: When Data Gets Encoded Twice
One of the most confusing things you'll meet while decoding is double encoding: data that was Base64-encoded, then encoded again. It happens when a pipeline encodes a value that's already encoded — an API encodes a JSON field containing a Base64 string, a logging system encodes an already-encoded token, a developer copy-pastes encoded output into an encoder "just to be safe." The symptom is distinctive: you decode once and get something that still looks like Base64 (high-entropy gibberish with = padding) instead of readable content.
The fix is simple once you recognize it: decode again. If the second decode yields readable text, you've found the problem — and you should fix the pipeline to encode exactly once, because every unnecessary encoding layer adds 33% size overhead and confuses the next person. A quick diagnostic: valid Base64 decodes to bytes that are either readable text or recognizable binary; if your first decode produces something that itself passes the "looks like Base64" test (multiple of 4 length, valid alphabet, maybe padding), decode it again before concluding anything about the content.
Reading Raw Email Source With a Decoder
Knowing how to decode MIME bodies turns email from a black box into an inspectable system. In Gmail, open a message, click the three-dot menu, and choose "Show original" — you'll see the raw message: headers, MIME boundaries, and the Base64 blocks carrying attachments. Each attachment section has headers like Content-Type: application/pdf; name="invoice.pdf" and Content-Transfer-Encoding: base64, followed by the encoded body.
Copy an attachment's encoded block into the decoder to verify its integrity independently of your mail client. If it decodes cleanly, the bytes on the wire are fine and the corruption is happening in the client's rendering. Compare the decoded size against the Content-Length or the file size the sender reports — a mismatch means truncation in transit. You can also decode suspicious attachments' filenames and content types before deciding whether to open them: phishing emails often disguise executables with double extensions, and the MIME headers reveal the true type. This kind of inspection is routine in email administration and incident response, and a fast decoder is the tool you reach for first.
More Decoding Scenarios
Mobile developers
The problem: Push notification payloads, deep-link parameters, and embedded config blobs arrive Base64-encoded, and a malformed value crashes the app on launch — but the crash log only shows the encoded string.
How this tool helps: Decode the offending value from the crash report to see what the app actually received: truncated JSON, an unexpected null, or a URL-safe string fed to a standard decoder. Five seconds of decoding often replaces an hour of guessing.
Technical writers
The problem: API documentation needs realistic examples of encoded fields — tokens, file-upload payloads, auth headers — but the examples in the draft were invented and don't actually decode to anything sensible.
How this tool helps: Generate real encoded values with the encoder, verify they decode to the documented plaintext, and ship examples that readers can actually follow along with instead of placeholder gibberish.
Identifying Decoded Files by Magic Bytes
When decoding yields binary instead of text, you can often identify the file type from its first few bytes — the "magic number." A decoded blob starting with iVBORw0KGgo in Base64 (which decodes to bytes 89 50 4E 47) is a PNG; /9j/ at the start means JPEG (bytes FF D8 FF); JVBERi0 decodes to "%PDF-". This trick is invaluable when an API returns an encoded file without a content type, or when you're verifying that an "image upload" endpoint actually received image bytes rather than something malicious. Decode the first few dozen characters, check the signature against a magic-bytes reference, and you'll know what you're holding before involving any heavier tooling. It's a small skill, but it's the difference between guessing and knowing when debugging binary APIs.
Frequently Asked Questions
How do I decode a data URI image?
Copy the full data URI (it starts with data:image/…;base64,), delete everything up to and including the comma, and paste the remainder into the decoder. If the original was text-based (like an SVG), you'll get readable markup back; for PNG/JPEG data URIs, the decoded bytes are binary image data rather than viewable text.
Why does decoding fail with an "invalid character" error?
Something in the string isn't in the Base64 alphabet: whitespace that wasn't stripped, a data-URI prefix left attached, smart quotes from a rich-text editor, a truncated copy, or URL-safe characters (- _) fed to a standard decoder. Clean the input and try again; the offending character is usually at the very start or end.
Can I decode URL-safe Base64 here?
Yes. URL-safe Base64 (used by JWTs) replaces + with - and / with _. Select the URL-safe mode if the tool doesn't auto-detect, and it will decode correctly. Mixing alphabets — decoding URL-safe input as standard — is one of the most common decoding failures.
The decoded output is gibberish — what went wrong?
Probably nothing: the original data was binary (an image, a PDF, a certificate), not text. Decoding binary to text produces mojibake because the bytes aren't valid character sequences. The decode itself succeeded — you just need a binary viewer, not a text box, for the result. Alternatively, the input may have been double-encoded; try decoding the output again.
How do I decode Base64 in my own code?
Every major language has it built in: atob() in browsers (use a UTF-8-safe wrapper for non-ASCII), base64.b64decode() in Python, Buffer.from(s, 'base64').toString() in Node.js, Convert.FromBase64String() in C#. For URL-safe variants, most libraries offer a parallel function (e.g., urlsafe_b64decode in Python).
Is decoding the same as decrypting?
No. Decoding reverses an encoding — a public, keyless transformation. Decrypting reverses encryption and requires the secret key. Calling Base64 "decryption" is a red flag in security discussions; if no key was involved, it was decoding, and the data was never protected.
Why does my JWT payload decode but the signature doesn't?
That's by design. The header and payload are JSON text, so they decode to readable content. The signature is raw cryptographic output — binary data that isn't meant to be read, only verified mathematically against the signing key. Gibberish in the third segment is normal and expected.
Can Base64 be decoded without the = padding?
Often, yes. Padding is redundant when the decoder can infer the length — many decoders accept unpadded input (common in URL-safe/JWT contexts). Strict decoders reject it, in which case re-add "=" characters until the length is a multiple of 4. This tool accepts both.
Is it safe to decode a suspicious string?
Decoding itself is safe — it's just a mathematical transformation producing text. The risk is in what you do after: decoded output may be a malicious script, a phishing URL, or exploit code. Read it, don't run it, and don't paste decoded secrets into other tools unnecessarily.
Is my pasted data stored?
No. Decoding is processed instantly and the input is never stored, logged, or retained. For live production tokens, prefer decoding in your own environment as a standing habit; for development and debugging, pasting here is fine.