Base64 Decoder

Base64 packs every 4 input characters back into 3 output bytes. Each character represents 6 bits, so 4 characters carry 24 bits, which is exactly 3 bytes. The decoder strips any padding, looks each character up in the 64-symbol alphabet (A-Z, a-z, 0-9, plus "+" and "/"), shifts the bits into place, and writes the raw bytes out. From there you can interpret those bytes as UTF-8 text, render them as hex, or print them as 8-bit binary groups.

Padding completes the final four-character group. Padded Base64 has a length that is a multiple of 4. One leftover source byte uses two pad characters, while two leftover bytes use one. Unpadded Base64 omits them. This decoder accepts both padded and unpadded input and restores missing padding internally.

RFC 4648 section 5 defines a URL-safe variant that swaps the standard "+" for "-" and "/" for "_". Those two original characters need percent-encoding inside URLs and break many filesystems, so JWTs, JSON Web Keys, and most web tokens use the URL-safe alphabet by default. Tick the URL-safe checkbox to flag your intent; the decoder accepts both alphabets either way, so paste-from-anywhere just works.

Because the original bytes are not UTF-8 text. Base64 can carry any binary data, including images, ZIPs, encrypted blobs, and protocol buffers, none of which decode to readable letters. Switch the output format to Hex or Binary to see the raw bytes. If you expected text and got garbage, double check that you copied the full string, that you are using the correct alphabet, and that the data was not encrypted or compressed before encoding.

No. Base64 is an encoding, not encryption. The transformation is fully reversible without any key, and anyone with the string can decode it instantly. Use base64 to move binary data through text-only channels like JSON, HTTP headers, or email, but never to protect passwords, API keys, or anything else that needs to stay secret. For confidentiality use a real cipher such as AES-GCM.