WordPress: File Type Not Permitted for Security Reasons

"Sorry, this file type is not permitted for security reasons" is what a WordPress upload fails with when the file's MIME type is not in the set of types your installation supports. It is a type check, not a size check, and the distinction matters — compressing the file will not make it go away.

WordPress's own documentation prints this message verbatim on the Network Admin Settings screen page for Multisite, and it explains the cause in the same paragraph. That pairing is unusually specific, and it points at the one mistake almost everybody makes when trying to fix this.

What this error actually means

Here is the official note, word for word, from the "Upload file types" section of the Network Admin Settings screen documentation:

"Note: Adding arbitrary file types will not work unless a corresponding function is also hooked to upload_mimes filter. See the wp_get_mime_types function in wp-includes/functions.php for the current default set of supported mime-types / file extensions. Adding mime types in the 'upload file types' field not listed in the default set will NOT work unless you've added them using the upload_mimes filter! Uploading files with mime types not supported (without adding them using the filter) will fail with the message "Sorry, this file type is not permitted for security reasons"."

Two separate things are being described there, and reading them as one thing is why people get stuck:

1. There is a list of file types WordPress accepts, and it comes from core, not from your settings screen.
2. Typing an extension into the settings field does not add it to that list. The documentation is emphatic about this — "will NOT work unless you've added them using the upload_mimes filter" is its own capitalised sentence.

Where does the accepted list come from? Core builds it in get_allowed_mime_types(), which starts from wp_get_mime_types() and then hands the result to the upload_mimes filter. The docblock on wp_get_mime_types() draws the line between the two filters plainly:

"This filter should be used to add, not remove, mime types. To remove mime types, use the 'upload_mimes' filter."

Two details from that function are worth knowing before you go hunting for a plugin conflict. get_allowed_mime_types() removes swf and exe unconditionally, and it removes htm|html and js for any user who does not have the unfiltered_html capability. So "what this site allows" is not one fixed table — it varies by who is logged in.

The settings field that looks like the fix but is not

On a Multisite network, Network Admin → Settings has an "Upload file types" field, and it reads like the obvious place to whitelist an extension. The same documentation page describes what is in it:

"The default list is populated by WordPress during network setup from get_allowed_mime_types(), which covers common image, video, audio, text, document, archive, and Office formats. The exact set of extensions varies between WordPress versions as new types are added; to see the current default for your installation, check the upload_filetypes value in the wp_sitemeta table or inspect wp_get_mime_types() in WordPress core."

Read that alongside the note above and the trap is clear. The field holds extensions that were already supported when the network was set up. Adding a new one to it, with no matching upload_mimes filter behind it, leaves you exactly where you started — and the upload still fails with the security-reasons message. Note too that the official answer to "what is in the default set on my install" is go look it up in the upload_filetypes value or in core, because the set changes between WordPress versions.

The fastest fix: send a format core already knows

If you do not maintain the site's code, the reliable move is to stop fighting the allow-list and hand WordPress something already in it. Core's default MIME map includes these video and audio extensions:

'avi'                          => 'video/avi',
'mov|qt'                       => 'video/quicktime',
'mpeg|mpg|mpe'                 => 'video/mpeg',
'mp4|m4v'                      => 'video/mp4',
'ogv'                          => 'video/ogg',
'webm'                         => 'video/webm',
'mkv'                          => 'video/x-matroska',
'3gp|3gpp'                     => 'video/3gpp',
'mp3|m4a|m4b'                  => 'audio/mpeg',
'wav|x-wav'                    => 'audio/wav',
'ogg|oga'                      => 'audio/ogg',
'flac'                         => 'audio/flac',

The keys are regular expressions, which is why .m4v rides along with .mp4 on video/mp4, and .mov with .qt on video/quicktime. One warning: this table maps extensions to MIME types, it is not a codec whitelist. WordPress's core documentation says nothing about which video codecs are supported — that layer simply is not covered.

Converting before you upload is not a workaround someone invented, either. It is what WordPress.com's own upload troubleshooting page tells you to do: "If you have images and other files in unsupported formats that you want to use, then you should convert them to a valid file type before uploading. You can do this with editing software or a free online converter."

That converter runs inside this page — the file is read from your disk and re-encoded locally, so nothing is uploaded anywhere on the way to fixing an upload. If your source is a QuickTime file, MOV to MP4 is the same job in one step; for WebM, use WebM to MP4. If you want to know how in-browser encoding works before trusting it with a client's footage, we wrote up browser video processing.

Other causes, in order of likelihood

The extension is genuinely outside core's default set. Check it against wp_get_mime_types() rather than against a blog post — the documentation is explicit that the exact set varies between WordPress versions.

It was added to the settings field but no filter was hooked. This is the case the official note exists to warn about. The extension appears in upload_filetypes, the upload still fails, and nothing in the interface tells you why.

Your user role is the variable. htm|html and js come out of the allowed list for users without unfiltered_html. If one account can upload a file and another cannot, the account is the difference, not the file.

You are on WordPress.com, not a self-hosted install. That is a different system with a different allow-list: "WordPress.com restricts uploads to the file types listed on this page. Restricting file types protects your site from unsafe files." Its troubleshooting page adds, "WordPress.com supports these common file types. Uploading any other file type causes an error." The documented wording there is different too — for an unsupported type the help center quotes "This file cannot be processed by the web server." and then says: "The file type is not supported. This message is not about the file's size."

You are seeing a different message than you think. The Audio block documentation quotes a separate editor error: "If you try to upload a file type that is not supported, the editor will display an error message: Sorry, this file type is not supported here." Two documented messages, two documentation pages — copy yours exactly before searching, because they are not interchangeable.

How to tell it worked

Upload the converted file and confirm it lands in the Media Library. If it does, the type check passed and you are done.

If it now fails with something about size instead, you have moved on to a different limit. On a Multisite network, the same Network Admin settings screen carries two more values — "Site upload space / Limit total size of files uploaded to [ 50 ] MB" and "Max upload file size / Default is [ 1500 ] KB" — and WordPress's documentation does not spell out how those interact with your server's PHP limits, so treat them as things to look at rather than a formula. More upload errors are collected in our fix guides.

FAQ

Why does WordPress say a file type is not permitted for security reasons? Because the file's MIME type is not in the set your installation supports. WordPress's Multisite documentation states that uploading files with mime types not supported "will fail with the message" — and then quotes this exact string.

I added the extension in Network Admin settings and it still fails. Why? Because that field alone does not do it. The official note says adding mime types in the upload file types field that are not in the default set "will NOT work unless you've added them using the upload_mimes filter."

Is this error about the file being too large? No — it is a type check. Size limits are separate settings, and on Multisite they live elsewhere on the same network settings screen.

Which video formats does WordPress core accept by default? Core's default map includes mp4|m4v, mov|qt, avi, mpeg|mpg|mpe, ogv, webm, mkv, 3gp|3gpp and more. The documentation warns the exact set varies between WordPress versions, so verify against wp_get_mime_types() for your install.

Can I convert the file without uploading it to a converter site? Yes. The tool on this page encodes in your browser, so the file never leaves your machine — see all Clapr tools for the rest of the converters.

Quotes from WordPress's Network Admin Settings screen and core function reference on developer.wordpress.org, and from the WordPress.com support center, checked 16 September 2026. The default set of allowed types changes between WordPress versions — verify against the official documentation before relying on it.