Privacy tool

Sanitize SVG

Strip scripts, event handlers and external references from an SVG so it is safe to serve or embed. The drawing itself comes out unchanged. Free, private, processed in memory.

SVG SVG
PrivConvert
Privacy-first conversion
No files stored
In-memory processing
Deleted instantly
No sign-up needed

Complete the security check to begin

An SVG is a document, and documents can be told what to do

Most file uploads are treated as data. You accept a JPEG, you store it, you serve it back, and there is nothing inside it that a browser will act on. SVG breaks that assumption. It is XML, the browser parses it as a document, and the specification gives that document real capabilities: it can define a script, it can attach a handler to a shape so that hovering over it triggers code, it can open a window onto embedded HTML, and it can point at resources living on other servers.

Whether those capabilities are exercised depends on how the file ends up being used. Inside an img tag the browser renders it in a restricted mode and scripts stay dormant. Inlined into a page, or opened at its own URL, it is a full document running in your site's origin. The trouble is that the decision about how to embed a file is usually made months after the decision to accept it, in a different part of the codebase, by someone who is thinking about layout rather than about what the file might contain.

So the file is cleaned rather than the embedding restricted. The document is parsed, checked against a list of what a drawing is allowed to contain, and written out again from the parsed structure. Anything that was not on the list is simply not there in the output.

  • Rebuilt from a parse tree against an allowlist, so an unrecognised vector fails closed
  • Scripts removed, including namespaced spellings a text-matching cleaner would miss
  • Every event-handler attribute removed, and animation cannot put one back
  • Embedded HTML, iframes and media elements removed
  • Entity and DOCTYPE declarations handled at the parser, closing file-read and expansion attacks
  • External references removed, so the drawing cannot report who viewed it
  • Shapes, paths, text, gradients, filters and animation preserved - verified pixel for pixel
  • A report of what was found, rather than a bare claim of success

If the drawing does not need to scale, converting it away from XML settles the matter completely - SVG to PNG gives you pixels with no document behind them. For the same problem in a different format, see Sanitize PDF.

If you are deciding how to handle SVG uploads in your own application, this guide covers the serving side - why the same file is harmless in one context and dangerous in another, and which common defences do not actually defend anything.

A converter built around your privacy

Most online tools upload your files to a server, keep them for days, and may mine them for AI training or resale. PrivConvert was built the opposite way - around your privacy.

No human ever sees it

Your files are handled entirely by automated code. No staff, partner or AI model ever reads, stores or trains on your data.

Zero data retention

Files are processed in volatile memory (RAM) and purged the instant your download is ready - nothing is ever written to disk, cached or backed up.

Encrypted transfers

Every upload and download is protected with TLS 1.3, so your file cannot be intercepted on the way to the server or back to you.

No account required

Convert instantly with no sign-up, no email and no profiling cookies. We never build a profile around you or the files you convert.

Built for people who value their privacy

Thousands of people trust PrivConvert with their files because privacy here is structural - enforced by how the service runs, not just promised.

250 MB Max file size
450+ Conversion tools
0 sec File retention
100% Free to use

Frequently Asked Questions

Why does an SVG need sanitizing when a PNG does not?
Because an SVG is not an image file in the way a PNG is - it is an XML document that a browser parses and renders. That document is allowed to contain a script element, attributes such as onload and onmouseover, embedded HTML through foreignObject, and references out to other addresses. A PNG is pixels and cannot do any of this. An SVG accepted as a user upload and then served back is a well-known route to cross-site scripting for exactly this reason.
When does the script in an SVG actually run?
It depends on how the file is used. An SVG placed in an img tag or set as a CSS background is rendered in a restricted mode where scripting does not execute. But an SVG inlined into the page markup, or opened directly at its own URL, is a full document and its scripts run with the privileges of your site's origin. Since the person uploading a file does not control how it will later be embedded, the safe assumption is that it will run.
How does this differ from stripping the dangerous parts with search and replace?
A pattern-based cleaner reads the file as text and deletes what it recognises. That fails in two well-documented ways. It is single pass, so a payload written as a tag nested inside another tag re-forms into a live tag once the inner match is deleted. And it matches literal spellings, so a namespaced variant slips through untouched. This tool takes the other approach: it parses the document into a tree with a hardened XML parser, keeps only elements and attributes that appear on an allowlist, and then writes a fresh document out from that tree. Because the output is rebuilt rather than edited, there is no leftover text for a browser to reinterpret.
What does the allowlist actually permit?
The drawing vocabulary: shapes, paths, groups, text, gradients, patterns, clipping paths, masks, markers, the filter primitives, and animation. Presentation and geometry attributes are allowed by name. Anything not on the list is removed rather than inspected, so a vector nobody has thought of yet fails closed instead of passing through.
What gets removed?
Script elements including namespaced spellings, every attribute beginning with 'on', foreignObject and any embedded HTML, iframes and media elements, XML entity and DOCTYPE declarations, references to javascript: addresses, references out to other servers, and CSS that imports remote stylesheets or uses expression syntax. An animation element that tries to assign to an event handler or to a link target is also removed, since that is a route to putting back a handler that was just taken away.
Does removing external references matter if they are not scripts?
Yes, for a different reason. An SVG can reference an image on another server, and when the drawing renders, the viewer's browser fetches it - which hands that server the viewer's address and the fact that they opened the file. It is the same mechanism as a tracking pixel in an email. Local references within the same document, which is how gradients and filters are wired together, are kept.
Will my graphic still look the same?
Yes. We verified this by rasterising files before and after sanitizing and comparing them pixel by pixel, using real icon sets and a test drawing exercising gradients, filters, clipping paths, text and animation. The output was identical in every case, and nothing was removed from files that were already clean.
What about XML entity attacks?
The parser is configured with entity resolution, DTD loading and network access all switched off, so an external entity declaration cannot read a file from the server and a nested entity definition cannot be expanded to exhaust memory. Both classes are handled at the parser rather than by trying to recognise them in the text.
Does it tell me what it found?
Yes. The result comes with a tally counting scripts, event handlers, external references and embedded HTML that were removed, and it reports plainly when a file was already clean. Through the API the tally is returned in an X-Sanitize-Report response header, so an upload pipeline can log which files arrived carrying something.
Can I run this on every upload automatically?
That is the intended use. It is part of the developer API as a plain HTTP endpoint with no parameters, so an application that accepts SVG avatars, logos or diagrams can pass each one through before storing it. Sanitizing on the way in is more reliable than remembering to sanitize on the way out.
Is my file uploaded or stored anywhere?
It is held in server memory for the length of the request and returned to you. It is never written to disk, never stored and never logged, and it is gone once your download finishes.
What if I would rather not serve SVG at all?
Converting to a raster format removes the question entirely, because the result is pixels with no document behind them. Use SVG to PNG if you do not need the drawing to scale.

Related Tools

Compress Image Sanitize PDF Redact PDF Remove EXIF Protect PDF HAR Sanitizer

Further Reading

SVG vs PNG: Which Format Should You Use? If Your App Accepts SVG Uploads, Read This First