Base64 Decoder — Decode Base64 Strings Online

Base64 decoding reads the encoded string four characters at a time. Each character is looked up in the Base64 alphabet table to recover the original 6-bit value. The four 6-bit values are then combined into three bytes of original data. Padding characters (=) at the end signal that the last group had fewer than three original bytes: one = means the last group produced two bytes, and == means it produced only one byte. The decoder must validate that every character in the input belongs to the Base64 alphabet, that = appears only at the end of the string, and that the total length is consistent. A valid Base64 string always has a total length (including padding) that is a multiple of four. Strings that fail these checks are invalid and cannot be decoded correctly without guessing about the missing data.

A valid standard Base64 string consists only of the characters A-Z, a-z, 0-9, +, and /, followed by zero, one, or two = padding characters at the end. Its total length including padding must be a multiple of four. URL-safe Base64 uses - instead of + and _ instead of /, and may omit the = padding entirely. If you receive a string that looks like Base64 but fails to decode, the most common causes are whitespace or newlines inserted by line-wrapping (common in email-formatted Base64), mixing of standard and URL-safe alphabets, missing or extra padding characters, and corruption or truncation during transmission. Stripping all whitespace and ensuring the correct alphabet and padding are present usually resolves decoding failures in practice.

Invalid Base64 data arises from several common sources. Line wrapping: MIME-encoded Base64, used in email, inserts a newline every 76 characters; the newlines must be stripped before decoding in contexts that do not expect them. Alphabet mismatch: standard Base64 uses + and /, while URL-safe Base64 uses - and _. Passing URL-safe Base64 to a standard decoder (or vice versa) causes failures for strings containing those differing characters. Truncation: if a Base64 string is cut off at a fixed character limit, the resulting fragment is not decodable. Padding errors: some systems strip the = padding from Base64 strings for use in URLs; a decoder that strictly requires padding will fail on such input. Understanding which variant your data source produces lets you pre-process the input appropriately before decoding.

In JavaScript, atob() throws a DOMException if the input is not valid Base64, so always wrap it in a try/catch block. In Python, base64.b64decode() raises a binascii.Error on invalid input; using validate=True makes it stricter about alphabet and padding conformance. In PHP, base64_decode() returns false on failure when the strict parameter is set to true, so always check the return value rather than assuming success. When building a user-facing application, catch decoding errors and display a clear message explaining that the input is not valid Base64, rather than showing a cryptic exception trace or silently returning empty output. This tool shows an error badge for invalid input so you can immediately identify malformed strings.

Decoding Base64 from untrusted sources carries security risks that developers often overlook. A Base64-encoded string can contain any bytes after decoding — including null bytes, binary sequences, executable code, or malicious HTML and script content. Never pass decoded output directly to eval(), innerHTML, or system command functions without sanitization. When decoding user-supplied Base64 that is supposed to represent a specific data type such as a JSON object or an image, validate the decoded output against the expected format before processing it further. Also enforce maximum size limits on input before decoding to prevent memory exhaustion in server-side code that handles untrusted requests, since large Base64 strings expand to substantial binary data after decoding.