You try to add a logo, an icon font, or a nice crisp SVG graphic to a page, and WordPress stops you cold: "Sorry, this file type is not permitted for security reasons." No file name, no extension hint, just a flat refusal. It's one of the more confusing WordPress errors because the file is fine — it opens, it's not corrupted, it's just not on WordPress's approved list. Here's what's actually happening and how to fix it without opening a security hole.

Symptom

You'll usually see one of these, depending on where the upload happens:

  • Media Library drag-and-drop shows a red error under the thumbnail: "Sorry, this file type is not permitted for security reasons."
  • A theme or plugin's custom uploader (logo field, icon picker, import tool) silently rejects the file or shows a generic "upload failed."
  • The file uploads fine over FTP or cPanel File Manager directly into wp-content/uploads, but it still won't attach through the WordPress admin.
  • It happens consistently for one file type — SVG, WebP, AVIF, ICO favicons, or font files like .woff2 — while JPGs and PNGs upload with no issue.

Cause

WordPress doesn't allow arbitrary uploads. It keeps an allowlist of file extensions and matching MIME types, built by the wp_get_mime_types() function, and every upload is checked against it by wp_check_filetype_and_ext(). If your file's extension isn't on that list — or its real content doesn't match what the extension claims — the upload gets rejected before it ever reaches your uploads folder.

A few specifics that trip people up:

  • SVG is never allowed by default. This isn't an oversight — an SVG is really an XML file, and XML can carry inline <script> tags. Letting anyone upload one is a straightforward path to stored XSS, so WordPress core deliberately leaves it off the list.
  • WebP has been allowed since WordPress 5.8, and AVIF since 6.5. If you're still seeing this error for those formats, you're almost certainly on an older WordPress version or the site is running a security plugin that overrides core's list.
  • Font files (.woff, .woff2, .ttf, .otf) and ICO icons are not in the default list either. Icon font plugins and custom favicon uploads hit this constantly.
  • The MIME check is content-aware, not just extension-based. Renaming a script to photo.jpg won't fool it — WordPress inspects the actual file signature (via PHP's finfo or the file's magic bytes) and rejects it if the content doesn't match a real image, font, or document type.
  • Security plugins add their own layer on top. Wordfence, iThemes Security, and All In One WP Security all ship upload restrictions that can block a file type even after you've allowed it in WordPress core.

Fix

Start by confirming exactly which extension is blocked and whether it's core WordPress or a plugin doing the blocking.

1. Check what WordPress currently allows

If you have terminal" class="auto-link">WP-CLI access (SSH into your VPS, or cPanel Terminal on shared hosting), run:

wp eval 'print_r(get_allowed_mime_types());'

That dumps the live allowlist for the site, including anything plugins have already added. It's the fastest way to confirm the extension really is missing rather than guessing.

2. Add the file type through the upload_mimes filter

For most non-SVG cases (fonts, ICO, a niche image format), the safe fix is a small snippet in your child theme's functions.php or a site-specific plugin:

function skyserver_custom_upload_mimes( $mimes ) {
    $mimes['woff']  = 'font/woff';
    $mimes['woff2'] = 'font/woff2';
    $mimes['ico']   = 'image/x-icon';
    return $mimes;
}
add_filter( 'upload_mimes', 'skyserver_custom_upload_mimes' );

Only add the extensions you actually need. Every entry you add is one more file type WordPress will accept from anyone with upload capability, so treat this list as a whitelist, not a wishlist.

3. Handle SVG separately, with sanitization

Don't just add 'svg' => 'image/svg+xml' to the filter above and call it done — that reopens the XSS risk core deliberately closed. Instead, install a plugin built to sanitize SVGs on upload, such as Safe SVG. It strips out scripts and event handlers from the file before allowing it through, so you get the graphic without the attack surface. If only admins ever need to upload SVGs, you can additionally restrict the capability so lower-privilege users still can't.

4. Check for a security plugin blocking it independently

If the WP-CLI check in step 1 shows your extension already listed but the upload still fails, the block is coming from a plugin, not core:

  • Wordfence: Firewall > All Firewall Options > look for upload-related rules, or temporarily disable the firewall to confirm.
  • All In One WP Security: Media > look for an upload restriction or file-type allowlist section.
  • iThemes Security: Check under System Tweaks for upload restrictions.

Disable the relevant rule temporarily, retry the upload, and re-enable it once you've confirmed the plugin was the culprit. That way you know whether to fix the plugin setting or the WordPress filter.

5. Rule out a server-side block

Occasionally the rejection isn't WordPress at all — it's ModSecurity on the server blocking the upload request before PHP sees it, which usually shows up as a generic failure rather than WordPress's specific wording. If you're on SkyServer cPanel hosting, check cPanel > Security > ModSecurity for any triggered rule tied to the upload, or check your error log via cPanel > Metrics > Errors. On a VPS, check /usr/local/apache/logs/error_log or your Nginx error log around the timestamp of the failed upload.

Prevention

  • Keep the upload_mimes list to exactly what your site needs — audit it after installing new plugins, since some quietly add their own entries.
  • Never add SVG support without a sanitizer plugin in front of it. This is the one shortcut that actually matters for security.
  • Restrict media upload capability to trusted roles if your site has open registration or multiple contributor accounts — fewer people who can upload means a smaller blast radius if a file type filter is ever misconfigured.
  • After a WordPress core update, re-check get_allowed_mime_types() — core occasionally expands the default list (as it did for WebP and AVIF), which can make an old custom filter redundant or, worse, conflict with it.

Frequently Asked Questions

Why does WordPress block SVG uploads by default?

An SVG file is XML, and XML can contain embedded scripts. Without sanitization, an uploaded SVG could execute JavaScript in an admin's browser when viewed — a stored XSS vulnerability. Core leaves SVG off the default allowlist specifically to prevent that.

Is it safe to just enable SVG uploads with a functions.php snippet?

Not on its own. A bare upload_mimes filter entry for SVG allows the file through with no scanning of its contents. Pair it with a sanitization plugin like Safe SVG, or don't enable it at all if you don't strictly need SVG uploads.

I added the file type to upload_mimes but it's still blocked. Why?

Two likely reasons: a security plugin (Wordfence, iThemes, All In One WP Security) is blocking it independently of core, or the file's actual content doesn't match its extension and fails WordPress's real MIME-type check. Try uploading a known-good file of that type to isolate which it is.

Can I just upload the file over FTP instead of through WordPress admin?

You can drop it directly into wp-content/uploads via FTP or cPanel File Manager, and it'll sit on disk fine. But it won't be registered in the Media Library as an attachment, so you'd need to reference its URL manually rather than using the media picker. It's a workaround, not a fix.

Does this affect plugin or theme installation too, not just media uploads?

No — plugin and theme ZIP uploads go through a separate check that mostly cares about valid ZIP structure and, on multisite, file size limits. The "file type not permitted" message specifically comes from the media upload MIME allowlist.