Published August 16, 2026 · 6 min read · by the Fig2WP team

"Sorry, This File Type Is Not Permitted for Security Reasons" in WordPress

The wording makes it sound like an accusation. It isn't — WordPress applies the same check to a company logo and to a PHP shell, because from the server's position at that moment they're both just bytes with a name attached. The check is crude on purpose.

Which of the two failures you have

Look at the extension you're uploading:

• SVG, AVIF on older installs, ICO, PSD, AI, ZIP, TTF, JSON — the type is genuinely not allowed. You need to widen the allowlist, and the section below explains which way is safe.
• PNG, JPG, GIF, WebP — the type is allowed, so the rejection is about contents, not format. Jump to the renamed-file trap. Nine times in ten that's the answer, and no code is involved.

What WordPress accepts out of the box

The image half of the default allowlist is short:

If you're being rejected for WebP on a site running anything current, the default allowlist isn't your problem — something else has narrowed it. See the other three things.

The renamed-file trap

WordPress does not trust the extension. It reads the file's actual signature — the first few bytes that identify PNG as PNG — and compares that against what the name promises. Disagreement means rejection, under this same message.

Renaming photo.webp to photo.png changes precisely nothing about its contents. It is still a WebP file, and WordPress will say so, in the least helpful way available.

Common ways to end up here without ever consciously renaming anything:

• A converter that changed the extension without re-encoding the data.
• An image saved from a browser, where the served format didn't match the URL's extension.
• A file exported as JPEG and later renamed to .png to "get transparency" — which does not work, and is covered in why your transparent PNG still has a background.
• A partially downloaded file: truncated, so the signature is intact but the file isn't. This more often surfaces as HTTP error.

The fix is always the same and never involves WordPress: open the file in something that can re-encode it, export it properly as the format you want, and upload that.

SVG, and why it's not an oversight

SVG is the single most-searched case here, so it deserves the real reason rather than a workaround.

An SVG is XML, and XML can contain <script>. A crafted SVG uploaded to your Media Library and rendered in an admin page executes in the context of a logged-in administrator. Any user who can upload media — a contributor, a customer on a form, a compromised author account — becomes a path to a full site takeover. That's why the format is off the list while JPEG, which cannot execute anything, is on it.

So the correct fix is not a snippet that adds image/svg+xml to the allowlist. That gets the upload working and leaves the hole wide open. Use a plugin that sanitises SVG on upload — one that strips scripts, event handlers and external references before the file is stored. If you can't, ship a PNG at 2x; for the icon sizes most sites actually use, the file-size difference is smaller than the argument.

Widening the allowlist safely

When you genuinely need an extra type, add exactly that type. In a small site-specific plugin:

add_filter('upload_mimes', function ($mimes) {
    $mimes['avif'] = 'image/avif';
    return $mimes;
});

Two things to avoid while you're in there:

• ALLOW_UNFILTERED_UPLOADS — this turns off the check for every file type, for administrators, permanently. It's the difference between unlocking one door and removing the frame. Plenty of forum answers recommend it; none of them are looking at your site's user list.
• Pairing upload_mimes with a filter that bypasses wp_check_filetype_and_ext — that's the contents check from the section above, and disabling it means WordPress will happily store a PHP file called logo.png.

Put the snippet in a plugin rather than functions.php, so switching themes doesn't silently break uploads.

The other three things that narrow it

1. A security plugin

Wordfence, Sucuri, iThemes and hardening plugins in general often trim the allowlist further, and some do it by default. Check the plugin's file-upload settings before writing any code — the setting you want usually already exists in a checkbox.

2. Multisite's network allowlist

A network has its own list at Network Admin → Settings → Upload file types, applied on top of core's. A type missing there is rejected on every site in the network, and no upload_mimes filter overrides it. This is the one that wastes the most time, because the code looks correct.

3. Your role

Some hardening setups restrict uploads by capability. If the same file uploads fine as an administrator and fails as an editor, stop looking at the file.

FAQ

What does this message actually mean?

Either the file type is outside the WordPress allowlist, or the type is allowed but the file's real contents don't match its extension. The same sentence covers both.

Why won't WordPress let me upload an SVG?

SVG is XML and can carry executable script, which makes an uploaded SVG a stored cross-site-scripting risk. Use a plugin that sanitises SVGs on upload rather than a snippet that only adds the MIME type.

Does WordPress support WebP?

Yes, since 5.8 — and AVIF since 6.5. A WebP rejection on a current version points at a security plugin, a multisite setting, or a file that isn't really WebP.

How do I allow a new file type?

Add the extension and MIME type via the upload_mimes filter in a small plugin. Don't reach for ALLOW_UNFILTERED_UPLOADS — it disables the check for everything at once.

Why is my PNG rejected when PNG is allowed?

Because it isn't a PNG. Renaming a file doesn't convert it, and WordPress reads the actual file signature. Re-export it in the format you want.

Can I turn the check off?

You can, and you shouldn't. The check is what stops an executable file being stored under an image's name. Widen the allowlist by one entry instead.