Base64 Inspector
Decode and inspect a Base64 or Base64URL string: validity with a specific failure reason, alphabet detection (standard vs URL-safe), padding correctness, decoded byte length, a hex/byte dump and a content-type guess (UTF-8 text, JSON, or binary with a recognized magic-byte signature).
Input
Standard and URL-safe Base64 are both accepted and auto-detected. Everything runs locally in your browser — nothing is uploaded.
Output
| Property | Value |
|---|---|
| No data yet | |
Decoded Preview
Hex Dump
Guides
Base64 Inspector decodes a Base64 (or Base64URL) string and reports on its structure, not just its content: whether it's valid and why not if it isn't, which alphabet it uses, whether its padding is correct, how many bytes it decodes to, a byte-level hex dump, and a best-effort guess at what the decoded content actually is.
This is different from a plain Base64 decoder: those hand you the decoded text and stop. Inspector is for when you need to know why a Base64 value won't decode, whether it's standard or URL-safe Base64, or what's actually inside a blob before you trust it — a JWT segment, an API token, a data URI, a config value someone pasted into a ticket.
How to use it
Paste a Base64 string into the input box. The report updates automatically and includes:
- Valid / Invalid, with a specific reason on failure — an invalid character (and its position), padding in the wrong place, too many
=characters, or a character count that can't be valid Base64 (a length that leaves remainder 1 when divided by 4 is never possible). - Alphabet — standard (
+//) or URL-safe (-/_), auto-detected from the characters present. A string using only letters, digits and=is valid under either alphabet and is reported as ambiguous. - Padding characters — how many trailing
=are present, or "unpadded" if none (URL-safe Base64 commonly omits padding, and that's accepted here). - Decoded byte length — the exact size of the decoded data.
- Content type guess — UTF-8 text, JSON (pretty-printed in the preview), or binary. For binary data, a handful of common magic-byte signatures are checked (PNG, JPEG, GIF, PDF, ZIP, GZIP, BMP, PostScript); anything else is reported as unrecognized binary rather than guessed at.
- Decoded preview — the decoded text (or pretty-printed JSON) when the content is valid UTF-8, otherwise a note pointing at the hex dump.
- Hex dump — the classic offset / hex / ASCII columns (
00000000: 4865 6c6c 6f2c … Hello,…), one row per 16 bytes, so you can see exactly what's inside a binary payload.
Is my data uploaded anywhere?
No. Everything — decoding, validation, the hex dump, the content guess — runs locally in your browser. Nothing you paste here is ever sent to a server, which matters if you're inspecting something sensitive like an auth token, a session cookie value, or an API secret encoded as Base64.
Why does it say my Base64 is invalid when another tool decoded it fine?
Some decoders are lenient — they'll silently ignore stray characters or guess at missing padding. This tool reports the string exactly as given: if it contains a character outside the Base64 alphabet, or padding is malformed, that's flagged rather than silently patched, so you can see precisely what's wrong with the source data.
What's the difference between standard and URL-safe Base64?
Standard Base64 uses + and / in its alphabet, which aren't safe to put directly in a URL or filename unescaped. URL-safe Base64 (also called Base64URL) swaps those for - and _, and is what you'll see in JWTs and many web APIs. The two alphabets can't be mixed in one string — a value using both is invalid.