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, this file type is not permitted for security reasons." 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 WordPress 7.0.2 (latest stable). 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): 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): the full default map of extensions to MIME types that WordPress ships with.
- upload_mimes filter (WordPress Developer Resources): the supported hook for adding or removing an allowed file type.
- wp_check_filetype_and_ext() (WordPress Developer Resources): 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 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.jsonexport, a.webpon 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 genericapplication/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
.jpgor.pngextension implies. - A file that was renamed rather than properly converted, an
.mp4that 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.
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.
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 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
.docxor 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_mimesbut still get the error. The second check is disagreeing about the file's real type. Add the matchingwp_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.phpand lost to a theme update. Move it to a child theme or, better, a must-use plugin inwp-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.
