Base64 turns arbitrary bytes into a 64-character alphabet (A–Z, a–z, 0–9, +, /) so binary data can travel safely through text-only channels — email bodies, JSON fields, URLs. It is not encryption and provides no confidentiality; it's purely a transport encoding, and roughly 4 characters of base64 represent 3 bytes of original data, which is why decoded content is always a bit shorter than its encoded form.
There are two alphabets in common use. Standard base64 uses + and / and pads with = to a multiple of 4 characters. Base64url swaps those two characters for - and _ so the output is safe to drop directly into a URL path or query string without percent-encoding — this is the variant JWTs use, and it's also why a standard base64 string with + or / in it will fail to decode if you naively treat it as base64url, and vice versa.
Once decoded, the interesting question is usually 'what did I just decode into?' — and the answer is in the first few bytes. File formats identify themselves with a fixed magic-number header: PNG starts with 0x89 P N G, JPEG starts with 0xFF 0xD8, GIF starts with GIF87a or GIF89a, ZIP (and anything built on the ZIP container, including .docx and .jar) starts with PK, and gzip starts with 0x1F 0x8B. Checking these bytes is far more reliable than trusting a file extension or a Content-Type header, both of which are just labels an attacker can lie about.
This decoder tries base64 first, then base64url if that fails, inspects the resulting bytes against a magic-number table, and — if it recognizes an image format — renders it directly so you can see what was hiding in the string without ever leaving the page or uploading anything.
Edge cases worth knowing
- A base64 string with no padding
- Padding (=) is technically required by the original spec but many real-world producers (including some JWT and URL-safe encoders) omit it. This decoder pads internally before decoding rather than rejecting valid-but-unpadded input.
- Decoded bytes that are themselves another encoded format
- Base64-encoding a JSON blob or a JWT is common in cookies and query parameters. When the decoded output is plain text, it's fed back through every matcher automatically — so a base64 string containing a JWT shows you the decoded JWT's claims in the same pass.
- A string that happens to be valid base64 but is actually something else
- Hex strings, short words, and random text can accidentally satisfy the base64 alphabet and length constraints. That's why base64 is shown as one candidate in the ranked stack rather than the only interpretation — check whether the decoded bytes are printable and meaningful before trusting the match.
Common mistakes
- Assuming base64 is a security measure — it hides nothing from anyone who bothers to decode it, which takes one line of code.
- Mixing up the standard and URL-safe alphabets and getting a decode failure that looks like corruption but is actually the wrong character set.
- Forgetting that decoded output can be binary — printing it directly to a terminal can produce garbled control characters instead of the image or file you expected.
- Trusting a file's claimed type instead of checking the actual magic bytes before processing an upload.