Data URIs let you inline a whole resource into a single string, which is handy for small assets but is also a favourite trick for smuggling executable content past naive filters. This tool decodes a data URI, shows exactly what it contains, and flags the patterns that make a data URI dangerous.
How it works
The tool parses the URI against the RFC 2397 shape data:[<mediatype>][;base64],<data>:
- It splits off the media type and the payload at the first comma, defaulting the type to
text/plain;charset=US-ASCIIwhen none is given. - It detects whether the payload is base64 or percent-encoded and decodes it, reporting both the encoded length and the decoded byte size.
- Safe raster image types (PNG, JPEG, GIF, WebP) are previewed inline directly from the URI. SVG is deliberately excluded from preview because it can run script.
- For textual payloads it inspects the decoded content for
<script>tags, inline event handlers, nesteddata:URIs, and oversized base64 blobs, raising the risk level accordingly.
Which MIME types are dangerous and why
| MIME type | Risk | Reason |
|---|---|---|
| text/html | High | Navigable; executes inline script when opened via window.open or iframe src |
| application/javascript | High | Executes directly when loaded as a script source |
| image/svg+xml | High | SVG is XML that can contain script elements and event handlers |
| text/plain | Low | Rendered as inert text; cannot execute |
| image/png, image/jpeg, image/gif, image/webp | Low | Inert binary; browser renders as pixels only |
| application/pdf | Medium | PDFs can contain embedded JavaScript; depends on viewer |
The tool assigns risk by MIME type first, then scans textual payloads for secondary
indicators like embedded event handlers (onerror=, onload=) and nested data:
URIs — a common obfuscation layer.
How data URIs are used in attacks
A data URI with a text/html type and inline script bypasses URL-based filters
because the URL begins with data:, not http:, and there is no hostname for a
blocklist to match. When loaded in a browser context (an iframe src, a popup, or
some email clients) the HTML executes, enabling cross-site scripting even without
a same-origin context. Attackers also base64-encode the payload to hide keywords
from simple string matchers — which is why inspecting the decoded content, not just
the encoded URI, is necessary.
Example
Paste this into the tool:
data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==The tool decodes the base64 to <script>alert(1)</script>, reports text/html as
the MIME type, flags the <script> tag in the payload, and marks the URI
high risk. Paste a small data:image/png;base64,... PNG and it previews the
image inline and reports low risk.
CSP interaction
Content Security Policy controls where data URIs are accepted:
img-src 'self' data:allows inlining images as data URIs (common for small icons).script-src data:is extremely dangerous and should never appear in a production CSP.frame-src data:similarly allows loading data-URI HTML in iframes — avoid it.
Use this inspector when auditing a CSP policy to understand what each data-URI permission actually permits.
Everything runs locally — suspicious input never leaves your browser.