Is It Safe to Open an SVG File? SVG Security Risks Explained

Most people file SVG under "picture format," mentally grouping it with JPG and PNG — pick a file, drop it in, done. That instinct is wrong in one specific and important way: a JPG or PNG is compressed pixel data with no way to execute anything, but an SVG is a plain-text XML document, and XML documents can contain markup that a browser is willing to run as code. Opening, embedding, or previewing an SVG from a source you don't fully trust is closer to opening an HTML file than opening a photo — and the gap between how people treat the two is exactly where the risk lives.

SVG is XML, not a picture format

Open any SVG file in a plain text editor and you'll see readable markup: `<svg>`, `<path>`, `<circle>`, `<rect>` and so on, each with attributes describing coordinates, colors and shapes. That's the whole format — there's no separate "safe" binary layer underneath it the way there is with a JPEG's compressed pixel stream. Because it's markup, an SVG can legally contain elements and attributes that have nothing to do with drawing shapes: a `<script>` element, or any of dozens of event-handler attributes that exist throughout the SVG specification for legitimate purposes like animating a shape or reacting to a click. Nothing about the .svg file extension or an `image/svg+xml` MIME type stops those from being present — validity as an image and capacity to carry executable behavior are two entirely separate questions.

The two ways an SVG can end up running code

There are two genuinely different mechanisms here, and conflating them is where a lot of confusion about "is SVG safe" comes from.

Script tags — usually blocked, but not always

You might expect a `<script>alert(1)</script>` embedded in an SVG to be the main danger, but modern browsers already close most of that door on their own: when markup is inserted into an already-loaded page via `innerHTML` (or React's `dangerouslySetInnerHTML`, which is the same underlying browser API), any `<script>` element it contains is parsed into the DOM but flagged as "already started" and never actually executes. This is standard, well-tested browser behavior, not something a developer has to remember to prevent — it holds for HTML `<script>` tags and SVG `<script>` tags alike. The exception is when the SVG isn't being inserted into an existing page at all, but loaded as its own top-level document — opened directly as a browser tab, or placed as the source of an `<iframe>` or `<object>`. In that case, the browser is genuinely parsing and loading a fresh document, scripts run exactly as they would on any HTML page, and a `<script>` element inside the SVG executes normally.

Event-handler attributes — the vector that works almost everywhere

This is the one that actually matters day to day, because it isn't blocked by the innerHTML protection above. SVG elements support the same family of event-handler attributes as HTML — `onload`, `onerror`, `onclick`, `onmouseover`, `onpointerover` — plus SVG-specific animation events like `onbegin` and `onend` from the SMIL animation elements (`<animate>`, `<set>`). When a browser parses one of these attributes, whether the markup arrived through a normal page load or through a dynamic `innerHTML` insertion, it compiles the attribute's content into a real event listener. It doesn't matter that the element was inserted programmatically rather than typed by hand in the original HTML — the listener still gets wired up, and it still fires when its triggering event occurs.

<!-- Fires when the (deliberately broken) embedded image fails to load -->
<svg xmlns="http://www.w3.org/2000/svg">
  <image href="does-not-exist.png" onerror="alert(document.location.hostname)" />
</svg>

<!-- Fires purely from a SMIL animation starting -->
<svg xmlns="http://www.w3.org/2000/svg">
  <animate onbegin="alert(1)" attributeName="x" dur="1s" />
</svg>

<!-- Fires just from a mouse hovering the rendered graphic -->
<svg xmlns="http://www.w3.org/2000/svg" width="200" height="200" onpointerover="alert(1)"></svg>

None of those three examples use `<script>` at all, and none of them need the SVG to be opened as its own top-level document — every one fires the moment the markup above is rendered inline in a page via `innerHTML`, and the last one doesn't even need a click; simply moving a mouse over the rendered shape is enough. That's the practical shape of the risk: not a rare edge case requiring an unusual delivery method, but ordinary attributes firing under ordinary rendering.

Where this actually becomes exploitable

The risk only turns into a real vulnerability in specific contexts, and it's worth being precise about which ones actually matter:

• A website renders user-uploaded SVG markup inline via innerHTML — the classic case is an avatar upload, an icon library admin panel, or a "paste your logo/SVG" tool that drops the raw markup straight into the page. If nothing strips event-handler attributes first, any visitor who views that content triggers the payload in their own browser, in the site's own origin.
• An untrusted .svg file is opened directly as a browser tab — double-clicking a downloaded SVG, or a link that opens one directly, loads it as its own top-level document rather than as an embedded image, so both `<script>` tags and event handlers execute in full.
• An SVG is loaded via `<iframe>` or `<object>` — both create a genuine nested document context, not an image context, so the same full execution applies as opening the file directly.

And just as important is what does not execute anything, because this is the safe default most sites already rely on without realizing it: an `<img src="file.svg">` tag, a CSS `background-image: url(file.svg)`, an SVG used as a `<link rel="icon">` favicon, or an SVG placed inside a `<picture>` element are all treated by the browser as an image resource, not a document or markup fragment — and browsers specifically refuse to execute scripts or fire event-handler attributes for content loaded this way, regardless of what the SVG itself contains. This is the single most useful fact in this whole topic: if you need to display an SVG from a source you don't fully trust, rendering it as an `<img>` rather than inlining its markup directly into the page is a complete, browser-enforced fix, with no sanitization step required at all.

A concrete example: what we found while building our own SVG Optimizer

This isn't hypothetical — it's exactly what turned up during a routine review of our own SVG Optimizer. The tool's live preview pane rendered whatever markup a visitor pasted or uploaded directly via `dangerouslySetInnerHTML`, on the reasonable-sounding assumption that it's "just showing a picture." Testing it with the payloads above confirmed all of them fired: an `<image>` element with a broken `href` and an `onerror` handler, an `<animate>` element with `onbegin`, an `<img>` nested inside a `<foreignObject>` with its own `onerror`, and — most strikingly — a bare `onpointerover` on the SVG's root element that fired from nothing more than a cursor passing over the rendered preview, no click, no broken resource, no user action beyond looking at the result. A visitor pasting in an SVG downloaded from somewhere else — exactly the realistic use case for an optimizer, "let me shrink this icon before I use it" — could have had arbitrary JavaScript run in their own browser, on this site's origin, just from the preview rendering. The fix was straightforward once identified: parse the markup with `DOMParser`, strip every `<script>` element and every attribute starting with `on`, neutralize any `javascript:` URL in an `href`, and only render the sanitized result — the actual optimize/copy/download text a visitor works with is never touched, only what gets piped into the preview.

How to render an untrusted SVG safely, if you're building something

• Prefer `<img>` or `background-image` over inline markup whenever the source isn't fully trusted. This is the simplest fix available, and it requires no sanitization logic at all — the browser's built-in image-context restriction does all the work.
• If you genuinely need inline SVG (to style it with CSS, animate individual paths, or manipulate it with JavaScript), sanitize first: strip `<script>` elements, every `on*` attribute, and any `javascript:` URL in an `href` or `xlink:href` before the markup ever reaches `innerHTML` or `dangerouslySetInnerHTML`.
• Use an established sanitizer for anything user-facing at scale — a library like DOMPurify (used with its SVG profile enabled) is a more complete, battle-tested solution than a hand-rolled attribute strip for a high-traffic, adversarial upload surface.
• Rasterize when you can — converting an uploaded SVG to a PNG via an offscreen `<canvas>` (`drawImage` followed by `toDataURL`) before storing or displaying it permanently removes every script-execution path, because the output is pixel data with nothing left to execute. This is exactly how logo uploads are handled across every business-document tool on this site.
• Add a Content Security Policy as defense in depth — a strict CSP that disallows inline event handlers (`script-src` without `'unsafe-inline'`) blocks some, though not all, of these vectors even if a sanitization step is ever missed somewhere. See our CSP explainer for how that works.

What this means if you're just a regular user with an SVG file, not a developer

The practical guidance for anyone who isn't writing the rendering code themselves is much simpler: treat an SVG from an unfamiliar source with the same caution you'd give an executable file, not a photo. Icons from well-established, reputable sources — Feather Icons, Heroicons, Font Awesome, an icon set bundled with a design tool you already trust, or a logo your own company issued — carry effectively no risk in practice, because there's no realistic incentive or opportunity for tampering. A "free icon pack" downloaded from an unfamiliar site, an SVG attachment in an unsolicited email, or a logo file someone you don't know sent you directly deserves more caution: don't double-click it to open it directly in a browser tab, and if you need to inspect what's actually inside before using it, open it in a plain text editor first and look for a `<script>` tag or any attribute starting with `on` before rendering it anywhere. Most image viewers, design tools like Figma or Illustrator, and OS-level thumbnail previews render SVG geometry without executing embedded script or firing event-handler attributes the way a web browser's page-rendering engine does, which is part of why this risk is specifically a web rendering concern rather than a general file-safety one — but a browser tab is exactly where most people end up looking at an SVG they were sent.

Is this an "SVG bug," or just ordinary XSS wearing a different file extension?

It's worth being precise here, because the honest answer undercuts a lot of alarmist framing: there's no special SVG-specific vulnerability class at work. This is the DOM's standard, decades-old event-handler-attribute execution model — the same mechanism behind classic HTML cross-site scripting — applied to a format most people mentally file under "safe media," the way they'd never file a `.html` attachment. The entire risk lives in that mismatch of expectations: developers sanitize user-submitted HTML as a matter of course, because everyone knows HTML can carry scripts, but the same instinct doesn't automatically extend to an "image" field that happens to accept SVG uploads, even though the underlying execution mechanism is identical. Recognizing that an SVG is markup, not a safe binary format, is really the entire lesson — everything else follows from that one correction.

Does converting or resizing an SVG remove the risk?

Yes, decisively, if the conversion actually rasterizes it. Running an SVG through a genuine image-processing step — drawing it onto an HTML `<canvas>` with `drawImage()` and re-exporting the canvas as a PNG via `toDataURL()` — produces a file that is, at that point, pure pixel data with no markup left in it at all; there is nothing left for a browser to parse as an event handler, because the format itself no longer supports one. This is exactly the technique this site's own tools already rely on for handling uploaded logos: every business-document generator that accepts a company logo (invoices, quotations, salary slips, and the rest) runs the uploaded file through a canvas before ever storing or displaying it, specifically so that even a maliciously crafted SVG logo upload comes out the other side as an inert raster image. A tool that merely resizes or re-encodes SVG *markup* without rasterizing it — including SVG-to-SVG "optimizers" that only reformat the text — does not remove this risk on its own unless it explicitly strips scripts and event handlers as part of that process, which is precisely the gap this site's own SVG Optimizer had until it was sanitized.

The short version: an SVG is a text document that can carry live, executable event handlers, not an inert picture — the risk is real but narrow and well understood, it activates specifically when SVG markup is rendered inline in a browser page (via `innerHTML`, a direct top-level open, or an `<iframe`/`<object>`), it does not activate when the same SVG is used as an `<img>` or CSS background image, and it disappears entirely once the file is rasterized into a true pixel format. Knowing which of those contexts you're actually in is most of what "is this SVG safe" comes down to.