WordPress "File Type Not Permitted": The Real Fix

You try to upload a logo or an icon to the WordPress media library and instead of the file landing in your library, you get a flat rejection: "Sorry, this file type is not permitted for security reasons." No file size warning, no permissions error — WordPress just refuses to touch it. This is almost always an SVG, WebP, or some other format outside WordPress's default whitelist, and the fix is different from the usual upload troubleshooting.

Why this is different from a normal upload failure

If you've dealt with WordPress upload errors before, your instinct is to check upload_max_filesize or folder permissions. Skip that here — this error fires before any of those checks even run. WordPress rejects the file at the type-validation stage, which means the file itself could be 2 KB and it would still bounce.

The giveaway is the exact wording. "Sorry, this file type is not permitted for security reasons" is WordPress core's message from wp_handle_upload() when a file extension isn't in the allowed MIME type list. Compare that to "HTTP error" or a stalled progress bar — those point at PHP limits or a security plugin, not this.

The other wording: "This file cannot be processed by the web server."

Drag a file into the Media Library and you may never see the "not permitted" message at all. The media uploader checks the file's extension in your browser before anything is sent, against a list WordPress builds from its allowed file types (get_allowed_mime_types()) — and when the extension isn't on that list, it says This file cannot be processed by the web server. instead. That's the same whitelist caught one step earlier, so the fixes below clear both messages: get_allowed_mime_types() runs the same upload_mimes filter, and once a type is allowed there the uploader accepts it too.

Cause: WordPress ships with a deliberately short whitelist

By default, WordPress allows common image, document, audio, and video formats — JPG, PNG, GIF, PDF, DOCX, MP3, and so on. It does not allow SVG out of the box, and it only allows WebP if your server's image library (GD or Imagick) actually supports it. A handful of other formats — ICO favicons in some setups, certain font files, AI/EPS design files — hit the same wall.

This isn't a bug or a hosting misconfiguration. It's intentional. Several of the blocked formats carry real risk:

• SVG is an XML file, and XML can embed <script> tags. An uploaded SVG can carry stored XSS if it's rendered directly in a browser without sanitization.
• WebP is safe from a security standpoint, but older WordPress versions and under-configured servers can't process it, so core gates it behind an image-library capability check.
• Anything with a double extension or a MIME type that doesn't match its content (e.g. a .jpg that's actually a PHP script) gets caught by the same validation, for obvious reasons.

Fix 1: Allow the file type with a targeted filter

The safest fix is a small snippet in your theme's functions.php (or, better, a small site-specific plugin so it survives a theme switch) that adds only the exact types you need — not a blanket "allow everything."

add_filter( 'upload_mimes', function ( $mimes ) {
    $mimes['svg']  = 'image/svg+xml';
    $mimes['webp'] = 'image/webp';
    return $mimes;
} );

On some WordPress versions this alone isn't enough, because a second, stricter check — wp_check_filetype_and_ext() — verifies the file's real content against its claimed type and can still reject SVGs. Pair the filter above with this one:

add_filter( 'wp_check_filetype_and_ext', function ( $data, $file, $filename, $mimes ) {
    if ( ! $data['ext'] ) {
        $check = wp_check_filetype( $filename, $mimes );
        $data['ext']  = $check['ext'];
        $data['type'] = $check['type'];
    }
    return $data;
}, 10, 4 );

Save, and try the upload again. No cache clear or server restart needed — both filters apply on the next page load.

Fix 2: Use a plugin if you'd rather not touch code

If editing functions.php isn't your thing, a plugin gets you the same result with a safety net:

• Safe SVG — allows SVG uploads but sanitizes them on the way in, stripping any embedded scripts. This is the one to use if you're not comfortable reviewing SVG files by hand.
• WP Add Mime Types — a general-purpose whitelist manager for any extension, useful if you need something more obscure like .ai or .eps for a design workflow.

Avoid plugins that blanket-allow "all file types" with one toggle. That reopens the door to the exact risk WordPress's whitelist exists to close.

SVG specifically: don't skip sanitization

If you enable SVG uploads with just the code filter above and nothing else, you're trusting every user who can upload media not to embed a malicious script. That's fine on a single-author site where you're the only uploader. It's not fine on a multi-author site, a client site where others have Author or Editor access, or anywhere user-submitted content ends up in the media library.

In those cases, either use Safe SVG (or a similar sanitizing plugin) instead of the raw filter, or restrict SVG upload capability to administrators only:

add_filter( 'upload_mimes', function ( $mimes ) {
    if ( ! current_user_can( 'administrator' ) ) {
        return $mimes;
    }
    $mimes['svg'] = 'image/svg+xml';
    return $mimes;
} );

WebP specifically: check server support first

If WebP still gets rejected after adding the upload_mimes filter, the block usually isn't WordPress anymore — it's the server's image library. Check under Tools → Site Health → Info → Media Handling for which image editor (Imagick or GD) is active and whether it lists WebP support. On Getwebup cPanel hosting, switching PHP versions in MultiPHP Manager to a build with Imagick's WebP module enabled usually resolves this; if you're not sure which PHP version has it, open a ticket and we'll check the server's compiled image libraries for you.

When it's not WordPress's whitelist at all

Occasionally the error text looks the same but the real blocker is upstream of WordPress entirely:

If you've added both filters above and SVG or WebP uploads still bounce with a 403 instead of WordPress's own message, the block is happening at the server firewall layer before your PHP code even runs — that's a different fix involving your hosting's security rules, not your theme files.

Prevention

• Only whitelist the exact extensions you actually need. Every format you add is one more thing that needs validating.
• Sanitize SVGs on upload, always — don't rely on "I trust my users."
• Keep the filter in a small site-specific plugin, not a theme's functions.php, so it survives a theme change.
• Re-check WebP support after any PHP version change — a downgrade can silently drop Imagick's WebP module.