A data: URI bundles a MIME type, an encoding (almost always base64), and the encoded content itself into a single string — data:image/png;base64,iVBORw0... — which is what lets an image live directly inside an HTML attribute, a CSS background-image property, or a JSON payload with no separate file request. It's genuinely useful for small icons and inline assets, and it's also a convenient place for a mismatch to hide, because nothing forces the declared image/png MIME type to actually match the bytes that follow it.
The only way to know what a blob of bytes actually is, independent of any label attached to it, is to check its magic number — the fixed byte sequence nearly every file format writes at the very start of the file specifically so file-type detection doesn't have to trust an extension or a header. PNG starts with the byte 0x89 followed by literal ASCII 'PNG'; JPEG starts with 0xFF 0xD8; GIF starts with the ASCII text GIF87a or GIF89a; WebP starts with RIFF followed by WEBP a few bytes later. A mismatch between the declared MIME type and the actual magic bytes is a real signal, not a cosmetic detail — it's a pattern used to smuggle unexpected file types past checks that only look at a Content-Type header or a data: URI's declared type.
Beyond the security angle, rendering the actual decoded image is often just the fastest way to answer 'what is this blob actually a picture of' when you're handed a giant base64 string with no other context — pasted from an API response, extracted from a database column, or found sitting in a config file with no comment explaining it.
This viewer accepts either a bare base64 string or a full data: URI, decodes the base64 payload, independently verifies the actual file signature against a magic-byte table regardless of what MIME type was declared, and renders the image directly if the bytes decode to a recognized image format — flagging explicitly if the declared type and the real signature disagree.
Edge cases worth knowing
- A data: URI whose declared MIME type doesn't match the actual bytes
- data:image/png;base64,... where the decoded bytes actually start with the JPEG magic number 0xFF 0xD8 is flagged explicitly — most image renderers will happily display it anyway since browsers typically sniff the real format, but the mismatch itself is worth knowing about wherever this URI came from.
- A base64 blob with no data: URI wrapper at all
- Plenty of contexts (API responses, database exports) store just the raw base64 payload without the data: scheme prefix or declared MIME type. This viewer decodes it and identifies the format purely from magic bytes in that case, since there's no declared type to cross-check against.
- An SVG passed as a data URI
- SVG is a text-based, XML format rather than a binary one with magic bytes — a data:image/svg+xml;base64,... blob decodes to plain text starting with <?xml or <svg. This viewer detects that case separately from binary magic-byte sniffing and renders it as an SVG, while noting that SVG can contain embedded JavaScript and should be treated with the same caution as any other executable content from an untrusted source.
Common mistakes
- Trusting a data: URI's declared MIME type as an assurance of what the content actually is, rather than checking the decoded bytes' real signature.
- Rendering an untrusted SVG data URI without considering that SVG can embed scripts, unlike genuinely static raster formats.
- Assuming a large base64 blob must be an image just because it appeared in an image-shaped field, without verifying the decoded magic bytes.
- Storing large base64-encoded assets directly in a database or JSON payload as a matter of course, when a reference to a stored file is usually far more efficient at any real scale.