"Sorry, This File Type Is Not Supported Here" in WordPress

"Sorry, this file type is not supported here" is WordPress's message for a file type that is not on the allowed list.

The useful part is that WordPress's own documentation spells out both the message and the list it is checking against, and that list is not the fixed, site-wide table most people assume it is.

What this error actually means

The wording appears verbatim in the official Audio block documentation, in its Troubleshooting section:

"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."

Note the cause it gives: a file type that is not supported. That is the only cause the page attaches to this string — it says nothing about bytes, bandwidth, PHP, or your hosting plan.

On a self-hosted WordPress install, the list being checked comes from core. The default mapping in wp_get_mime_types() is a table of extension patterns to MIME types, and the video and audio rows include entries like these:

'mov|qt'                       => 'video/quicktime',
'mp4|m4v'                      => 'video/mp4',
'webm'                         => 'video/webm',
'mkv'                          => 'video/x-matroska',
'mp3|m4a|m4b'                  => 'audio/mpeg',
'wav|x-wav'                    => 'audio/wav',
'flac'                         => 'audio/flac',

Two things follow directly from the source. The keys are regular expressions, so .m4v and .mp4 share one MIME type, and .mp3, .m4a and .m4b all map to audio/mpeg. And what the table maps is extension patterns to MIME types — it is not a codec list. WordPress's official documentation says nothing about which video codecs are supported; if that is what you need to know, check the official documentation rather than a guide like this one.

The list is built per user, not per site

This is the detail that explains the cases where one person can upload a file and another, on the same site, cannot. What actually runs at upload time is not the raw table above but get_allowed_mime_types(), whose function body is published in the core reference:

function get_allowed_mime_types( $user = null ) {
	$t = wp_get_mime_types();

	unset( $t['swf'], $t['exe'] );
	if ( function_exists( 'current_user_can' ) ) {
		$unfiltered = $user ? user_can( $user, 'unfiltered_html' ) : current_user_can( 'unfiltered_html' );
	}

	if ( empty( $unfiltered ) ) {
		unset( $t['htm|html'], $t['js'] );
	}

	return apply_filters( 'upload_mimes', $t, $user );
}

Read it line by line and you get three facts with no guesswork attached:

1. swf and exe are removed unconditionally — no role, no filter argument, they are simply gone.
2. htm|html and js are removed only when the user lacks the unfiltered_html capability. The function even takes a $user argument, so the answer to "is this type allowed" is a per-user answer.
3. Everything else passes through the upload_mimes filter, which is where plugins and themes add or subtract types.

That third line is also the supported way to change the list. The core docblock for wp_get_mime_types() is explicit about the division of labour:

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

The fastest fix: hand WordPress a type that is on the list

Since the check is on the type, the fix is to change the type. WordPress.com's own upload troubleshooting page recommends exactly this, in its own words:

"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."

.webm is the most common casualty here, and it is the clearest case of the two official lists not matching. The core reference for wp_get_mime_types() has 'webm' => 'video/webm' in its default table. WordPress.com's Accepted file types page names .webm as an extension that is not listed there: "If you need to upload a file extension not listed on this page, such as .mobile, .epub, or .webm, you can add support for these file types via a plugin—plugin-enabled sites run on more advanced infrastructure that can support file types not normally accepted." The two lists apply to different environments — read whichever one matches where your site is hosted. MP4 appears on both, which makes it the safe target.

This runs in your browser, so the file never leaves your machine — no second upload to worry about while you are fixing the first one. If your source is a QuickTime file from a Mac or iPhone, MOV to MP4 lands on the same video/mp4 row of the core table. Going the other direction, MP4 to WebM is only useful on installs where .webm is allowed.

Other causes, in order of likelihood

You are on a Multisite network, and the message is worded differently. Multisite has its own Upload file types field in the Network Admin settings, and the official handbook gives a different string for a rejection there: "Sorry, this file type is not permitted for security reasons". Same family of problem, different screen. The handbook also warns that the field alone is not enough: "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!"

You are on WordPress.com, where the wording changes again. Its troubleshooting page lists the upload errors and what each one means, including: ""This file cannot be processed by the web server." The file type is not supported. This message is not about the file's size." The Accepted file types page frames the restriction as deliberate: "WordPress.com restricts uploads to the file types listed on this page. Restricting file types protects your site from unsafe files."

Your WordPress version's default set is not the one you read about. The Multisite handbook says so directly: "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."

How to tell it worked

If the converted file lands in the Media Library, the type was the issue. If you now get a different message about size or the server, you have moved on to a different limit entirely, and the fix is a different one. Note that get_allowed_mime_types() takes a $user argument, so the allowed list it returns is the list for whichever account is doing the upload.

FAQ

What does the official documentation say this message means? The official Audio block documentation attributes it to "a file type that is not supported", and gives no other cause for this particular string. Separately, and on a different platform, WordPress.com's troubleshooting page says of its own message "This file cannot be processed by the web server." that "This message is not about the file's size." — that line belongs to that message, not to this one.

Why can an administrator upload a file that I cannot? Because get_allowed_mime_types() is evaluated per user. It removes htm|html and js for anyone without the unfiltered_html capability, and it accepts a user argument so the result can differ between accounts on the same site.

Can I upload .webm to WordPress? It depends which WordPress you are on. webm is in core's default wp_get_mime_types() table. WordPress.com's Accepted file types page names .webm as an extension not listed there that requires a plugin.

What does the allowed list actually check? The documented mapping in wp_get_mime_types() goes from extension patterns to MIME types, and get_allowed_mime_types() then trims that table. WordPress's documentation does not state anything about codec support — check the official documentation if that is what you need.

Where do I see the full list my install accepts? Check the upload_filetypes value in the wp_sitemeta table or inspect wp_get_mime_types() in core, as the Multisite handbook recommends — the set varies between WordPress versions.

More format and upload fixes are in the fix archive, including why Google Drive will not play your WebM. Every converter mentioned here runs locally in your browser — see all Clapr tools.

Quotes above are from WordPress's official Audio block, core function reference and Multisite handbook pages, and from WordPress.com's Accepted file types and upload troubleshooting pages, checked 16 September 2026. Verify against the official documentation before relying on them.