Base64 Decoder

Base64 represents binary data with a restricted set of printable ASCII characters. A decoder reverses that representation: each group of four encoded characters normally becomes three original bytes. It does not inherently return words, JSON, an image, or a document. Those meanings come from interpreting the resulting bytes with the correct character encoding or file format.

This distinction explains why some valid Base64 turns into readable text while other valid input looks like noise. If the bytes form well-formed UTF-8, LiveParse can show their Unicode text. If they do not, the honest representation is hexadecimal or a downloaded binary file. Replacing invalid byte sequences with the Unicode replacement character would hide data loss, so this decoder labels such content as binary instead of pretending it is text.

Base64 also contains no filename, content type, compression flag, checksum, or security guarantee. A surrounding protocol may provide those facts. A Data URL, for example, can carry a media-type label, but that label is metadata supplied by the sender rather than proof of the bytes’ true format. Use file signatures, protocol documentation, and application-level integrity checks when the origin is untrusted.

A Base64 string is built from 24-bit groups. Three source bytes become four six-bit symbols. When the final group contains only one or two source bytes, standard Base64 uses one or two = characters to mark the shortened ending. An encoded data length can therefore end with no padding, one =, or two ==, but padding is never allowed in the middle.

Strict validation checks the chosen alphabet, total length, padding position, and the unused low-order bits in the final symbol. Those unused bits are called pad bits and must be zero in canonical RFC 4648 output. Multiple non-canonical strings can otherwise decode to the same bytes, which is undesirable for signatures, cache keys, comparisons, deduplication, and systems that require one stable textual representation.

LiveParse exposes whitespace and padding as separate policies instead of hiding them behind one “strict” switch. You can reject whitespace while forbidding padding for JWS, reject whitespace while requiring standard padding, or ignore ASCII whitespace while allowing omitted padding for a documented wrapped format. Every combination still rejects invalid characters, mixed standard and URL-safe alphabets, impossible lengths, misplaced padding, and non-zero canonical pad bits.

When verifying a signature or reproducing a protocol message, validate the original text under that protocol’s exact rules before normalizing. Decoding and re-encoding may create a canonical string, but it cannot prove the sender originally supplied that form. The diagnostic output shows the detected alphabet and whether whitespace or padding was normalized so the transformation remains visible.

A plain .b64, .base64, or text file usually contains only encoded characters, sometimes wrapped onto several lines. Load it into the decoder, choose the correct alphabet, and inspect the reported normalization. The tool reads the selected file in the current browser tab and can download the recovered bytes. The 10 MB input limit is a browser-safety boundary designed to reduce long freezes and memory spikes, not a limit in the Base64 specification.

A Data URL combines a header and payload, such as data:image/png;base64,iVBORw0…. The header may declare a media type and parameters; the comma separates it from the encoded bytes. LiveParse parses the Base64 form and reports its label, but does not assume the label is true. For images, preview eligibility is based on recognized raster signatures in the decoded bytes.

Previewing untrusted active content inside a page creates unnecessary risk. This decoder never renders decoded HTML or SVG and does not execute scripts, open documents, or hand arbitrary bytes to a plugin. It previews only recognized PNG, JPEG, GIF, and WebP raster data. Everything else remains text, hex, or a download that you can examine with an appropriate isolated tool.

Large decoded results are shortened in the on-page preview so the interface remains responsive. Copy and download actions operate on the complete result. If the data is sensitive, remember that clipboard managers, downloaded files, browser extensions, backups, and operating-system history exist outside the converter’s control.