---
title: "How to Fix the \"Sorry, This File Type Is Not Permitted for Security Reasons\" Error"
description: "Fix the WordPress error saying a file type is not permitted for security reasons by re-saving the file or allowing one extra type with the upload_mimes filter."
url: "https://docs.noiz.ie/wordpress/how-to-fix-the-sorry-this-file-type-is-not-permitted-for-security-reasons-error/"
section: "WordPress"
categories:
  - "Applications > WordPress > WordPress Troubleshooting"
last_reviewed: "27 July 2026, against the current WordPress release"
---

# How to Fix the \"Sorry, This File Type Is Not Permitted for Security Reasons\" Error

You try to add a file to your WordPress site, the upload runs for a moment, and then it stops with a red message: **"Sorry, you are not allowed to upload this file type."** Older WordPress releases worded it **"Sorry, this file type is not permitted for security reasons,"** which is why the message is still searched for under that name. This guide explains why WordPress refuses the file, and walks you through the fixes in order from the safest to the one you should almost never use. You will learn how to tell whether the file itself is the problem, how to allow one specific file type in a controlled way, and why the "just allow everything" switch is a genuine security risk rather than a convenience. It is written for Noiz clients who manage their own WordPress site, and it fills in the parts the official documentation leaves unsaid: how WordPress really decides what is "permitted", the surprising reason a perfectly ordinary file sometimes gets rejected, and where on Noiz hosting to safely make a change without breaking anything.

**Last reviewed:** 27 July 2026, against the current WordPress release. This guide is written for Noiz hosting and is kept current against WordPress. It complements, and does not replace, the official WordPress documentation linked below.

### Official Documentation Reference

- [get\_allowed\_mime\_types() (WordPress Developer Resources)](https://developer.wordpress.org/reference/functions/get_allowed_mime_types/): the function that decides which file types your site accepts, and the capability rules that trim the list per user.
- [wp\_get\_mime\_types() (WordPress Developer Resources)](https://developer.wordpress.org/reference/functions/wp_get_mime_types/): the full default map of extensions to MIME types that WordPress ships with.
- [upload\_mimes filter (WordPress Developer Resources)](https://developer.wordpress.org/reference/hooks/upload_mimes/): the supported hook for adding or removing an allowed file type.
- [wp\_check\_filetype\_and\_ext() (WordPress Developer Resources)](https://developer.wordpress.org/reference/functions/wp_check_filetype_and_ext/): the second check that inspects a file's real contents, and the reason some valid files are still rejected.

## Prerequisites

- You can [log in to your WordPress admin dashboard](/wordpress/how-to-log-in-to-the-wordpress-dashboard/) as an administrator. The list of file types allowed depends on your role, and only an administrator can change it.
- For the code-based fix, a way to reach your site's files: an SFTP client, or the File Manager in your Noiz hosting panel. Editing the wrong file, or editing without a backup, can take a site offline, so work on a copy where you can.
- A recent, restorable backup before you edit any theme file or `wp-config.php`.

## Why WordPress Blocks the File

WordPress does not accept just any file into your media library. It keeps a deliberate allow-list of file types, and anything not on that list is turned away with the "not permitted for security reasons" message. Understanding the reason for that list is the difference between a safe fix and one that opens a hole in your site.

The list exists because your media folder is web-accessible. If WordPress let anyone upload, say, a `.php` file, an attacker who found a way to reach the upload form could drop an executable script onto your server and then run it simply by visiting its URL. That single weakness is behind a large share of real WordPress compromises. The allow-list is the wall that stops it, which is why the message frames the block as a *security* decision and not a limitation to be casually switched off.

### The two checks every upload has to pass

What most guides gloss over is that WordPress runs **two separate checks**, and either one can produce this error. Knowing which one stopped you tells you which fix you actually need.

- **Check one, the allow-list.** WordPress compares the file's extension against the types returned by `get_allowed_mime_types()`. That set starts from a large built-in map of common formats and is then trimmed to suit the current user. If the extension is not on the list, the upload is refused before the file is even examined. This is the usual cause when you are uploading something genuinely uncommon, an SVG icon, a font file, a `.json` export, a `.webp` on a very old install.
- **Check two, the real contents.** Even for an allowed extension, WordPress then calls `wp_check_filetype_and_ext()`, which uses the server's file-inspection library to read the file's actual bytes and confirm they match what the extension claims. If the detected type disagrees with the extension, the file is rejected with the same message, even though the extension itself is perfectly acceptable.

### The gotcha: a valid file rejected anyway

That second check is the source of the most confusing version of this problem, where a file you know is fine, a normal Word document or a re-exported photo, is refused as "not permitted". It happens because the content-inspection library and WordPress do not always agree on what a file is:

- A modern Office document (`.docx`, `.xlsx`, `.pptx`) is internally a compressed archive, so the inspector often reports it as a generic `application/zip`. WordPress expects the specific Office MIME type, sees a mismatch, and blocks it.
- An image re-saved or exported by some editors can carry a slightly different internal signature from what its `.jpg` or `.png` extension implies.
- A file that was renamed rather than properly converted, an `.mp4` that is really a `.mov`, for instance, will be caught precisely because the check is doing its job.

The practical takeaway: if the file is one WordPress should normally accept, the answer is almost never to loosen your site's security. It is to fix the file, which is the first method below.

![The WordPress Upload Media screen showing a failed upload with the red error message reading Sorry, you are not allowed to upload this file type](/images/kb/316_wordpress-file-type-not-permitted-error.png)

## Method 1: Convert or Re-save the File (Safest, No Code)

Before changing any site setting, deal with the file. This is the right first move for two of the situations above: a file in an everyday format that was wrongly rejected, and a file whose format you do not truly need to keep.

### Use a format WordPress already accepts

WordPress ships accepting a wide range of formats out of the box, so you may not need the exact one you have. Common images (`.jpg`, `.png`, `.gif`, `.webp`, `.avif`, `.ico`), documents (`.pdf`, `.doc`, `.docx`, `.xls`, `.xlsx`, `.ppt`, `.pptx`, and the OpenDocument equivalents), audio (`.mp3`, `.m4a`, `.wav`, `.ogg`, `.flac`) and video (`.mp4`, `.mov`, `.avi`, `.webm`) are all allowed as standard. If you are trying to upload a niche format, ask whether an accepted one would do the job: export a design as `.png` or `.pdf` rather than the source file, or a diagram as `.svg`'s safer cousin `.png`.

### Re-save a file that "should" work

When the format is one WordPress supports but the upload still fails, the content check has flagged a mismatch. Open the file in a proper application for its type and use **Save As** or **Export** to write a clean copy, rather than just renaming the extension. Re-saving a document from its Office application, or re-exporting an image from an image editor, rebuilds the file so its real contents and its extension line up, and the upload then passes. This solves the "valid file rejected" gotcha without touching your site at all.

## Method 2: Allow One File Type With a Filter (Controlled)

If you genuinely need a format WordPress does not accept, and you have decided it is safe to allow, add **only that one type** using the supported `upload_mimes` filter. This is the clean, surgical option: it widens the allow-list by exactly one entry and leaves every other protection in place.

### Where to put the code on Noiz hosting

Do not paste this into the parent theme's `functions.php`, because a theme update will wipe it out. The two durable homes for a snippet like this are a **child theme's** `functions.php`, or a small **must-use plugin**, a single `.php` file placed in `wp-content/mu-plugins/` that WordPress loads automatically and that no update or theme switch can disturb. The must-use plugin is the tidier choice because it keeps this behaviour independent of whichever theme you are running.

Reach either location through **SFTP** or your Noiz hosting panel's **File Manager**, both of which get you into `wp-content/`. If you are on a managed plan and would rather not edit files yourself, the Noiz support team can add a snippet like this for you; tell them exactly which file type you need to allow and why.

### The snippet

The filter receives the current allow-list as an array keyed by extension, and you add your entry. This example allows SVG images; change the extension and MIME type to suit the format you actually need.

```
add_filter( 'upload_mimes', function ( $mimes ) {
    // Add ONE type you have decided is safe. Example: SVG.
    $mimes['svg'] = 'image/svg+xml';
    return $mimes;
} );
```

### When the filter alone is not enough

Here is the detail that sends people in circles: for some formats, adding the extension to `upload_mimes` still leaves you with the same error, because the content check from earlier disagrees about the file's real type. SVG is the classic example, since the inspection library may report an SVG as plain text or generic XML rather than `image/svg+xml`. When that happens you also have to reassure the content check, by hooking `wp_check_filetype_and_ext()` for that one extension:

```
add_filter( 'wp_check_filetype_and_ext', function ( $data, $file, $filename, $mimes ) {
    if ( ! empty( $data['ext'] ) && ! empty( $data['type'] ) ) {
        return $data; // Already resolved, leave it alone.
    }
    $check = wp_check_filetype( $filename, $mimes );
    if ( 'svg' === $check['ext'] ) {
        $data['ext']  = 'svg';
        $data['type'] = 'image/svg+xml';
    }
    return $data;
}, 10, 4 );
```

Do this only for a specific extension you trust, as shown, never as a blanket "accept whatever the inspector says" rule, which would defeat the whole point of the second check.

<!-- IMG: wordpress-mu-plugin-upload-mimes-snippet | alt: A file manager view of wp-content/mu-plugins containing a small PHP file with the upload_mimes filter snippet that allows one additional file type -->

## Method 3: Use a File-type Management Plugin

If you are not comfortable editing PHP, a dedicated file-type or MIME-management plugin gives you the same result through a settings screen: you pick the extensions to allow from a list, and the plugin registers them with the `upload_mimes` filter for you. Several reputable plugins in the WordPress plugin directory do exactly this, and any of them is a reasonable choice; the point here is the approach, not a particular product.

Two cautions apply whichever plugin you choose. First, prefer one that lets you enable **specific** types rather than throwing the doors open, so you are still making a deliberate decision about each format. Second, a plugin that is installed only to flip one switch is a permanent piece of code, and therefore a permanent thing to keep updated. For a single extra type, the one-off `upload_mimes` snippet in Method 2 is often the lighter-weight answer, because it adds no ongoing maintenance.

## The ALLOW\_UNFILTERED\_UPLOADS Route, and Why to Avoid It

You will find advice online to add one line to `wp-config.php` that makes the error disappear entirely:

```
define( 'ALLOW_UNFILTERED_UPLOADS', true );
```

It works, and that is exactly the problem. This constant does not add one format; it **switches off the file-type check altogether** for the highest-level users, meaning administrators on a single site, and only network super admins on a WordPress multisite network. From then on those accounts can upload *anything*, including executable `.php` scripts, which is precisely the attack the allow-list exists to prevent.

The danger is not hypothetical. If any administrator account is ever compromised through a weak password or a phished login, this setting turns that break-in into full remote code execution on your server. It also bypasses the content-mismatch check, so the safety net that catches disguised files is gone too. For these reasons:

- WordPress deliberately hides this behind a config-file edit and never exposes it in the dashboard.
- Security scanners commonly flag its presence as a vulnerability, and some managed environments disallow it.
- There is almost no situation where it is the correct fix. If you think you need it, you actually need Method 2 for the one or two formats in question.

If you have already added this line, remove it now, and make sure it is not left enabled after any one-off task. Then work through the [WordPress Security Checklist](/wordpress/wordpress-security-checklist/) to confirm nothing was uploaded while it was active.

## A Word on SVG and Other Risky Formats

Some formats are blocked by default not because they are exotic but because they can carry code. An **SVG** is a plain-text image built from XML, and that XML can contain embedded JavaScript, which means a malicious SVG uploaded to your site can become a stored cross-site-scripting attack against anyone who views it. HTML files (`.html`) and JavaScript files (`.js`) are restricted for the same reason and are only offered to users trusted with unfiltered content. So if you do allow SVGs by the methods above, treat every SVG as untrusted: sanitise uploaded SVGs (a good SVG-support plugin does this automatically), and do not allow uploads from users you do not fully trust. Allowing a risky format is a decision to accept and manage that risk, not a step to take lightly.

## Troubleshooting

- **Symptom**: an everyday file such as a `.docx` or a photo is rejected as not permitted. This is the content-mismatch check, not the allow-list. Re-save or re-export the file from its proper application (Method 1) rather than renaming it, and the fresh copy will upload.
- **Symptom**: you added the type to `upload_mimes` but still get the error. The second check is disagreeing about the file's real type. Add the matching `wp_check_filetype_and_ext()` filter for that one extension, as shown in Method 2.
- **Symptom**: your snippet works but vanishes after a while. It was added to the parent theme's `functions.php` and lost to a theme update. Move it to a child theme or, better, a must-use plugin in `wp-content/mu-plugins/`.
- **Symptom**: the message mentions a maximum size rather than a file type, for example "exceeds the maximum upload size". That is a different problem entirely, a server upload limit, and none of the fixes here apply; it is solved by raising the PHP upload limits, which the Noiz support team can adjust for you.
- **Symptom**: you run a WordPress **multisite** network and an allowed type is still refused. Multisite keeps its own network-wide list of permitted extensions under **Network Admin > Settings > Upload Settings**. Add the extension there as well as in any filter.
- **Symptom**: the upload fails but you never see the WordPress error at all, or you get a plain server error page. That points to a server-level block rather than WordPress. If you are hosted with Noiz, open a ticket so support can check whether a security rule on the server is intercepting the upload.

If you are unsure whether a particular file type is safe to allow, or you would like the Noiz support team to add a controlled `upload_mimes` snippet for you, open a support ticket and include your domain, the exact file type you need, and what you use it for. On managed plans the team can make the change and confirm it is done in the safest way for your site.

---
Source: https://docs.noiz.ie/wordpress/how-to-fix-the-sorry-this-file-type-is-not-permitted-for-security-reasons-error/