SVG files in the WordPress media library: why the upload fails and how to enable it safely
You tried to drag an SVG file into the WordPress media library and WordPress said no. The error message is brief and unhelpful: “Sorry, this file type is not permitted for security reasons.” No follow-up, no suggestion of what to do next.
The useful question here is not how to force WordPress to accept the upload. It’s whether WordPress should, and what you’re agreeing to when you say yes.
Why WordPress blocks SVG by default
Think about the difference between a JPEG and a Word document. A JPEG is pixel data and colour values. It displays; that’s all it does. A Word document is different: it can carry macros, embedded instructions that run when someone opens the file. You can build something in a Word document that does things, not just shows things.
SVGs are much closer to Word documents than to JPEGs, even though they look like images. SVG stands for Scalable Vector Graphics, and the format is XML, the same kind of structured text a browser reads when it renders a webpage. And just like HTML, an SVG file can contain <script> tags. JavaScript. Instructions that run in a browser when someone views the file.
That capability is a feature of the SVG format, a genuinely useful one for interactive graphics. But it’s also why WordPress cannot treat SVGs the same way it treats PNGs. On a multi-author site, if a user with media upload permissions can upload an SVG with an embedded script, they can run code in other users’ browsers. A logged-in administrator clicking a crafted image in the media library could trigger a cross-site scripting attack from inside their own WordPress install.
So the block is a considered security call on WordPress’s part. The right response to it is to understand what you’re overriding before you do.
An SVG file is closer to a Word document than to a JPEG. It can carry embedded scripts, which is exactly why WordPress blocks it by default.
What enabling SVG support involves
The most common solution you’ll find online is a filter: a few lines of PHP that add image/svg+xml to WordPress’s list of allowed MIME types. This works. It also means anyone with media upload permissions on your site can now upload SVG files, embedded scripts included. If your site has contributors, authors, or client logins, you’ve opened that door for all of them.
A better approach is to sanitize SVG uploads on the way in. The Safe SVG plugin does this: it allows SVG uploads but strips out script tags and potentially dangerous attributes before the file is saved to your media library. It catches the main attack patterns without blocking SVGs entirely, and it’s a meaningful improvement over a raw MIME-type filter.
| Option | What it does | Who can get a script onto the site | Fits when |
|---|---|---|---|
| Leave the block in place | WordPress keeps refusing the upload | Nobody | Nobody on the site needs SVG in the library |
| Raw MIME-type filter | Adds image/svg+xml to the allowed types | Anyone with media upload permission | You are the only person who uploads |
| Safe SVG plugin | Allows the upload, strips scripts and dangerous attributes first | Nobody, for the patterns it recognises | Contributors, authors, or client logins share the install |
Which approach makes sense depends on who uploads files on your site. A single-author personal site has a different risk profile than a university department site with a dozen editors, or a media company with a content team cycling through freelancers. The right answer varies by site, and a generic MIME-type filter copied from a Stack Overflow post doesn’t know your user roster.
Why this matters for teams
SVG support comes up in team WordPress training because it looks like a technical question but is really a judgment call about risk. And judgment calls made without context tend to go in one of two directions: either SVGs get blocked entirely because nobody on the team knows how to enable them safely, or someone pastes a MIME-type filter from Stack Overflow without thinking about who else has upload access on that install.
Once you understand why WordPress blocks SVGs, the decision gets easier. You look at who has upload access and what the SVGs are for, and you make a call that fits the real risk profile. That’s the kind of working knowledge that makes a team more effective with WordPress, capable of making calls that fit rather than executing instructions someone else found online. It’s the same thing I aimed for when I compressed a newsroom’s WordPress training into two days: the decisions they would face, ahead of the settings they would click.
The enabling itself is a ten-minute job. The understanding is what most guides stop short of, and it’s why the same question tends to come up on the next install, and the one after that.
If your team runs into questions like this regularly, decisions about WordPress that require judgment as much as technical knowledge, I build customized training programs for organizations across Canada. Onsite in the Niagara region, or online, and built around what your team runs into rather than a generic WordPress curriculum.