Why Script Tags Don't Execute in SVG Preview — The img+Blob Safety Trick
SVG is both an image format and an XML document at the same time. And inside an XML document, you can put a <script> tag, along with event-handler attributes like onload and onclick. In other words, a single SVG file can effectively behave like a tiny web page — which is exactly why it's a well-known XSS (cross-site scripting) attack vector when you carelessly open an SVG from an untrusted source. And yet, this site's SVG Viewer — like most safe SVG preview tools — does nothing at all when you paste in an SVG containing a script. Why is that?
1. SVG is, by design, a format that can execute scripts
If you open an SVG file directly in the browser's address bar, or embed one in an HTML document using an <object>, <iframe>, or <embed> tag, that SVG is treated as a full, independent document context. In that case, any <script> tags and event handlers inside it run as normal. The same is true if you insert SVG markup as a string directly into the DOM via innerHTML — the script executes there too. Any tool that renders user-pasted SVG code through one of these paths is directly exposed to XSS.
2. The defense this tool uses: img + Blob
This site's SVG Viewer first parses the submitted code with DOMParser to check for syntax errors (a <parsererror> element). If parsing succeeds, it wraps the original code string, unchanged, in a Blob (MIME type image/svg+xml), creates a temporary URL with URL.createObjectURL(), and sets that as the src of an <img> tag to display it. That's the key move — the browser spec treats a resource loaded via an <img> tag as a "static image context," and in that context, even if the image happens to be SVG (XML), any scripts or event handlers inside it never execute. This isn't accidental behavior — it's a security boundary that browser vendors deliberately built in.
<img src="blob:..."> is only ever rendered (its shape gets drawn) — the document context in which its code would "run" is never even created. Loading SVG through an <img> tag gets exactly the same security treatment as loading a raster image like a PNG or JPG.
3. The dangerous ways to render it, by contrast
| Rendering method | Does the script execute? |
|---|---|
<img src="..."> (Blob URL / data URI) | ❌ No — safe |
element.innerHTML = svgCode | ✅ Yes — dangerous |
<object data="..." type="image/svg+xml"> | ✅ Yes — dangerous |
<iframe src="..."> | ✅ Yes — dangerous (though cross-origin isolation does apply) |
CSS background-image: url(...) | ❌ No — safe |
<object> and <iframe> treat SVG as a fully independent document, so scripts inside it come alive. <img> and CSS background-image, on the other hand, treat SVG as a pure picture and nothing more. If you're building a web service that needs to preview SVGs a user has uploaded or pasted in, you should always use the <img> approach.
4. Bonus: why zoom doesn't lose any quality
This tool's zoom feature doesn't re-render the image — it scales the already-displayed element up or down using CSS transform:scale(). Since SVG is a vector format defined by mathematical paths rather than pixels, it stays crisp even zoomed in up to 4x, without the pixelation you'd see with a raster image.
5. What if you actually need inline SVG?
Sometimes you genuinely need to insert SVG inline — for interactive animation or CSS styling that has to target individual elements inside the SVG. In that case, rather than giving up the <img> approach, the standard alternative is to strip out dangerous elements — <script>, event handlers, <foreignObject>, and the like — with a library like DOMPurify using its SVG profile (USE_PROFILES: {svg: true}) before inserting it.
Frequently Asked Questions
Q. If an SVG has a script tag inside it, does it run?
A. Not with this tool. Code that parses successfully is wrapped in a Blob and displayed as the src of an <img> tag — and browsers fundamentally block scripts and event handlers on any SVG loaded as an image.
Q. Do SVGs with CSS animation or SMIL animation still play?
A. Yes. An SVG shown via an img tag only blocks scripts — CSS animation and SMIL animation (like <animate>) are part of the image's own rendering behavior, so they play back normally.
Q. So is this approach 100% safe?
A. From the standpoint of script execution, yes, it's safe. That said, while the img+Blob approach blocks XSS, an SVG that references an external resource (such as <image xlink:href="external URL">) can still trigger that resource request — so an extremely security-sensitive service might want additional content validation on top of this.
Q. Is any tool that uses innerHTML to insert SVG dangerous?
A. It's dangerous if it inserts user-supplied SVG directly via innerHTML without validating or sanitizing it first. But if a service is inserting SVG it generated itself — with no user input mixed in — there's no risk. The danger comes specifically from putting "untrusted input" into a context where it can execute.