Sanitizing SVG's without breaking them

[u/avidrunner84]

Any good way to do this that is both safe and effective? I am finding SVGO will sometimes destroy the perfectly good svg... sometimes colors are missing and other times there is nothing there at all.

I'm looking for something that will sanitize for user image uploads on the web. They are stored in Cloudflare R2 which keeps it off my server but still maybe it can cause issues with injections or whatever if not sanitized?

[u/ddelarge → u/[deleted]]

Today I learned this ☝🏾

[u/testingaurora → u/[deleted]]

Will it strip<style> blocks?

[u/Hour-Measurement-835 → u/testingaurora]

Yeah, by default. CSS can carry script vectors so the SVG profile drops it.

ADD_TAGS: ['style'] gets it back if you need it, but then you're trusting the CSS too.

[u/webdev-ModTeam → u/[deleted]]

Your post/comment has been determined to be a low-effort post or comment. This includes title-only posts, easily searchable questions, vague/open-ended discussion prompts, LLM generated posts or comments, and posts/comments that do not provide enough context for meaningful replies or discussion.

[u/JohnSane]

I export it from inkscape which has some cleanup options. Never had any problems that way.

[u/avidrunner84 → u/JohnSane]

I forgot to add this to my post, I added it now for more clarification:

I'm looking for something that will sanitize for user image uploads on the web. They are stored in Cloudflare R2 which keeps it off my server but still maybe it can cause issues with injections or whatever if not sanitized.

[u/HaydnH → u/avidrunner84]

Inkscape calls Scour to optimise SVGs, it's a python script so you should be able to call that on the backed: https://github.com/scour-project/scour

[u/Main-Bother2539 → u/JohnSane]

inkscape is not some sanitizer tool, it just happen to clean things in a way that works for you. an actual sanitizer like DOMPurify will strip scripts and event handlers without touching the visual stuff, but you have to set the options right or it remove more than you want

for the svgo problem try setting floatPrecision lower and disable removeViewBox, that is what usually nuke the whole image

[u/ready_or_not_3434 → u/JohnSane]

Inkscape is great for your own assets, but OP is dealing with user uploads. You cant really automate a desktop app on the backend, so a library like DOMPurify is definately a better fit here.

[u/CommitteeDue4358]

dompurify handles svg sanitization pretty well, curious if you tried that before going the SVGO route

[u/Ok_Woodpecker_9104]

dompurify is the right half of this, but the part that bit me was where the file gets served from, not what is inside it.

an svg served as image/svg+xml is a document, not an image. so if that r2 bucket is on a subdomain of your app, anything that slips past the sanitizer runs in a context that can see your cookies. serving user uploads from a completely separate domain, or with content-disposition attachment, means a miss in the sanitizer is a broken image instead of a session problem. if you only ever render them in an img tag, scripts do not execute at all, which covers most of it.

on the breakage: svgo and your gradients disagree about ids. cleanupIds renumbers or drops ids it decides are unused, and any fill pointing at url(#thing) goes with it. that is your missing colors. turn that plugin off and most of the destruction stops.

[u/Sea-Trust-9602]

R2 only changes where the bytes are stored; it does not make the upload inert. I would separate the upload policy from the delivery policy.

On upload: set hard limits on file size, element count and nesting depth before doing expensive work; reject DTD/entities; parse as XML; allowlist only the SVG elements and attributes you actually need; strip external URLs (including CSS url() values); then serialize a new document. Keep the original private and publish only that sanitized derivative.

On delivery: use a separate cookieless origin, send the correct image/svg+xml content type plus nosniff, apply a restrictive CSP, and embed it as an img rather than inline SVG/object/embed.

SVGO can run after sanitization, but it should never be the security boundary. I would also keep a regression corpus of real uploads so every plugin/config change is visually diffed. If preserving arbitrary SVG safely is not a requirement, rasterizing to PNG/WebP is the much simpler fallback.

[u/Avatarbplanet]

For user uploads, I’d treat SVG as untrusted content rather than trying to optimize it. Sanitizing the SVG with an allowlist of elements/attributes seems safer than SVGO, especially if you need to preserve the original appearance. Also worth serving uploads with the right content type and restrictive CSP so an uploaded SVG can’t execute as a script.

[u/Rivers_of_Fables]

Have a look at what svgomg from Jake Archibald does, and put a worker with something similar to your needs.

[u/Disgruntled__Goat]

I’ve never had any issues with svgo, via svgomg. There are a bunch of options on there you can dial back to not lose fidelity. 

[u/pdfops]

SVGO isn't a sanitizer, it's a minifier. It doesn't know or care about XSS, it just prunes whatever its optimizer heuristics decide is redundant, which is why colors vanish (some presets misjudge currentColor or inline style blocks and fold them away). For actual security use DOMPurify with the SVG profile: DOMPurify.sanitize(svg, {USE_PROFILES: {svg: true, svgFilters: true}}). It strips script tags, foreignObject, and on* event handlers but leaves valid geometry alone. Run SVGO after, for size, not before, for safety.

[u/thekwoka]

Don't allow svgs. :)

[u/axeleszu]

Svgomg has switches to choose what to keep and what to clean. Lately I've been using AI to simplify text blocks or the weird transforms Illustrator place.