Base64 Validator
A strict RFC 4648 validator: alphabet, padding, length and canonical pad-bit checks with four distinct verdicts and the canonical form on offer. Not just does it decode, but is it right.
File to Base64
Drag a file here or browse
Any file type · up to 50 MB · converted locally in bounded chunks, the file never leaves your browser
Base64 to file
Paste Base64 or a full data: URI. The decoded size is estimated before anything runs, the type is verified against the actual bytes, and you can download the result.
Strict Base64 validator (RFC 4648)
Checks alphabet, padding, length and canonical pad bits. Valid, canonical, normalized and malformed are four different verdicts, and this validator tells you which one you have.
Base64 ↔ hex
Bounded at 2 MB of data per direction. Bytes with no valid UTF-8 meaning are fine here: hex is the binary-safe view.
Valid, canonical, normalized, malformed: four different things
"Is this valid Base64" is really four questions. Does it decode at all? Could a conforming encoder have produced exactly this string? Was anything silently adjusted to make it decode, like ignoring wrapping or mapping alphabets? And if it fails, where and why? This validator answers each one separately: the verdict line distinguishes canonical from merely decodable, every normalization is labeled instead of hidden, and malformed input gets the exact character position and rule it breaks. Try Zh== to see the canonical check that most validators are missing.
Base64 validation FAQ
What does this validator check that others do not?
Canonicity. Most validators only test the character set and length, so they accept Zh== as valid. It decodes, but RFC 4648 requires the unused bits of the final character to be zero, and a conforming encoder would always produce Zg== for the same byte. This validator distinguishes four verdicts: valid and canonical, valid but not canonical, decodable but suspect (mixed alphabets), and malformed, with the reason and the canonical form shown.
Why does canonical Base64 matter for security?
Because non-canonical encodings mean multiple strings decode to the same bytes. Systems that compare, cache, deduplicate or sign the encoded string rather than the decoded bytes can be tricked into treating identical data as different, or different-looking requests as new: this class of bug has appeared in token validation and signature-bypass advisories. If an encoded value is used as a key or compared anywhere, it must be canonical.
What are the length rules for Base64?
Unpadded Base64 length modulo 4 can be 0, 2 or 3, never 1: every 3 bytes make 4 characters, a final single byte makes 2 characters, and a final pair makes 3. Padded Base64 must be a multiple of 4 with at most two = signs at the very end. A remainder of 1 is mathematically impossible and almost always means the string was truncated, which is one of the most useful diagnoses this validator gives.
What does "mixed alphabets" mean and why is it flagged?
Standard Base64 uses + and /, the URL-safe variant uses - and _. One conforming encoder produces one alphabet, so a payload containing both is a red flag: typically two strings concatenated, a partial search-and-replace, or corruption in transit. The validator flags it as suspect rather than failing it, because it still decodes, but you should find out why it happened before trusting the data.
Can this validator fix a broken Base64 string?
It normalizes what is safely normalizable: non-canonical pad bits can be zeroed with one click (shown as the canonical form), URL-safe characters can be mapped to standard, and whitespace wrapping is ignored. What it will not do is guess missing characters: a truncated string has lost real data, and the honest answer is the diagnosis, not an invented repair.
More free tools: Full Base64 Workbench · Base64 to Text · Text to Base64 · JSON Formatter