SVG Security Linter

What this tool does

SVG is not a picture format — it is an XML document with a scripting model. An .svg file can carry a <script> element, an onload= attribute, a javascript: link, a <foreignObject> full of HTML, a DOCTYPE that pulls in a local file, or a reference to a server you do not control. That is why user-uploaded avatars, logos and icon packs are a recurring XSS vector: the file passes an image MIME check, then gets served back and inlined into a page.

Paste the markup and this linter walks it as text and reports every construct that makes the file dangerous, ranked high, medium or low, each with a line and column, a rule code, the element and attribute involved, and the source snippet that triggered it. Line and column both matter here, because real-world SVGs arrive minified onto a single line where "line 1" tells you nothing.

The report opens with a verdict:

• unsafe — at least one high-severity finding. Do not inline this file.
• review — findings exist, but none are high. Usually external references, data: URLs, or an unknown namespace.
• clean — nothing matched.

Pick Ranked report while you are reading, JSON to gate a CI job on verdict, or CSV to paste findings into a spreadsheet or a ticket.

Worked example

Input — a plausible-looking icon that is four separate attacks:

<svg xmlns="http://www.w3.org/2000/svg" onload="alert(1)">
  <script>alert(document.domain)</script>
  <a href="javascript:alert(2)" target="_blank"><text>go</text></a>
  <image href="https://evil.example/pixel.png"/>
</svg>

Output with Minimum severity = All and Output format = Ranked report:

SVG security lint · verdict: unsafe · 5 findings · 3 high · 1 medium · 1 low

L1:41 [high] EVENT-HANDLER: <svg> onload — 'onload' is an inline event handler: its JavaScript runs when the event fires, with no <script> element anywhere in the file
  <svg xmlns="http://www.w3.org/2000/svg" onload="alert(1)">

L2:3 [high] SCRIPT: <script> — <script> element runs JavaScript when the SVG is opened directly or inlined into a page (it stays inert inside an <img> tag, but not in an <object>, <iframe> or inline <svg>)
  <script>alert(document.domain)</script>

L3:3 [low] ANCHOR-TARGET: <a> target — <a target="_blank"> without rel="noopener" hands the opened page a window.opener reference it can use to redirect the original tab
  <a href="javascript:alert(2)" target="_blank"><text>go</text></a>

L3:6 [high] JS-URL: <a> href — 'href' points at a javascript: URL; activating the reference executes the code
  <a href="javascript:alert(2)" target="_blank"><text>go</text></a>

L4:10 [medium] EXTERNAL-REF: <image> href — 'href' references an external host (https://evil.example/pixel.png); rendering the file makes that request, which leaks the viewer's IP and user agent and lets the remote host swap the content later
  <image href="https://evil.example/pixel.png"/>

Raise Minimum severity to High only and the same input still reads verdict: unsafe, lists the three high findings, and closes with:

2 finding(s) below the selected severity are hidden; the verdict above still counts them.

A hand-authored icon with no active content returns:

SVG security lint · verdict: clean · 0 findings · 0 high · 0 medium · 0 low

No XSS-risk constructs found.

Rule codes

Limits and edge cases

• This is a reporter, not a sanitizer. It never emits a "cleaned" file, on purpose. A blocklist scrub of untrusted SVG gives false assurance — the bypass list is long and keeps growing. If you accept SVG uploads, run an allowlist-based parser server-side, or serve the files from a separate origin with Content-Disposition: attachment and a restrictive CSP.
• Nothing is rendered, fetched or uploaded. The markup is scanned as text in WebAssembly in your browser. No DOM parses it, no entity is resolved, no URL in the file is requested, and no byte leaves the page.
• Input is capped at 1,000,000 bytes. Larger input is rejected with an error rather than silently truncated, so a partial scan can never be mistaken for a full one.
• At most 500 findings are listed. If a file exceeds that, the overflow is stated explicitly at the end of the report — never dropped in silence.
• Minimum severity is a display filter only. The verdict is computed before it is applied, so raising the threshold can never turn an unsafe file into a clean-looking report; hidden rows are counted in the closing note.
• Allow external references is a policy switch, and it does change the verdict. Turn it on only when remote http(s) references are genuinely acceptable in your pipeline — for example an icon set that legitimately points at your own CDN. It drops EXTERNAL-REF findings entirely; every other rule is untouched.
• Ignore rule codes also changes the verdict, because suppressed findings are removed before it is computed. An unrecognised code is an error, not a silent no-op, so a typo can never quietly disable a rule.
• The scanner is deliberately forgiving. Malformed markup is scanned as far as it parses instead of being rejected, because hostile files are frequently not well-formed. That means a badly broken document may under-report; it will not be waved through as clean by a parse error.
• Comments and CDATA sections are skipped, so a <script> written inside <!-- ... --> is not reported. This matches how a browser treats them, and keeps documented examples from producing noise.
• Clean is not the same as safe. A verdict of clean means none of the 14 rules matched. It says nothing about whether the graphic renders as expected, whether it is enormous, or whether it exploits a renderer bug.

FAQ