Converting a WebM to MP4 before uploading to WordPress.com is not a workaround someone on a forum invented — it is the action WordPress.com's own documentation points at. Its accepted file types page names .webm by hand as an extension that page does not cover, and its upload troubleshooting page prescribes converting unsupported files before you upload them.
This page gives the command, maps every flag onto a line WordPress.com actually publishes, and is explicit about the places where the official documentation stops.
Why MP4 is the target
Three official lists, read together, make MP4 the only sensible destination for a WordPress.com upload.
The accepted file types page does not list .webm. Under Video it publishes .mp4, .m4v, .mpg, .mov, .vtt, .avi, .ogv, .wmv, .3gp and .3g2. The same page then names the extension explicitly in its Other formats section:
"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."
VideoPress is not the escape hatch either. It publishes a shorter list of its own — "MP4 (.mp4, .m4v)", "QuickTime (.mov)", "Windows Media Video (.wmv)", "AVI (.avi)", "MPEG (.mpg)", "Ogg (.ogv)", "3GPP (.3gp)", "3GPP2 (.3g2)" — and WebM is not on it. That list is introduced with the word "including", so it is not presented as a complete whitelist, but nothing official adds .webm to it.
And the conversion itself is official advice. From the WordPress.com troubleshooting page: "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."
MP4 is also where a VideoPress upload ends up anyway: "When you upload a video, VideoPress automatically converts it to MP4 format using H.264 video and AAC audio compression." That sentence is published about VideoPress specifically — whether an ordinary Video block upload gets transcoded is not something WordPress's official documentation states.
If your site is self-hosted rather than on WordPress.com, the rules are different — core's own MIME map contains 'webm' => 'video/webm'. That split is covered in WordPress WebM upload not supported.
The command
ffmpeg -i input.webm \
-c:v libx264 -b:v 8000k \
-c:a aac -b:a 160k \
-movflags +faststart \
wordpress-video.mp4Said plainly: WordPress does not publish FFmpeg commands. It publishes a recommended specification and names a different tool for hitting it — "a tool like HandBrake can be used to convert it before you upload it to the Media Library." The flags above express that same specification on the command line.
What each flag does
Each one maps onto a row of WordPress.com's recommended video settings table:
| Flag | WordPress.com's wording |
|---|---|
-c:v libx264 | "Format h.264" |
-b:v 8000k | "8mbps for 1080p30, 12mbps for 1080p60" |
-c:a aac -b:a 160k | "AAC minimum 160kbps" |
-movflags +faststart | "Fast Start / Web Optimized / progressive download" |
Three of those deserve more than a table row.
-b:v 8000k is a recommendation, not a rule. WordPress prints its own qualifier inside the table cell: "recommended, but other values are OK". Treat 8 Mbps as a starting point for 1080p30 rather than a threshold you have to clear.
-b:a 160k is a floor, not a target. The spec says "minimum 160kbps", so encoding audio higher is inside the recommendation; encoding lower is not.
-movflags +faststart matches a layout WordPress names. Its Other Settings row reads "Fast Start / Web Optimized / progressive download (so the whole file doesn't need to be downloaded before playback can begin)", and the HandBrake instructions repeat it as a checkbox to tick, alongside selecting MP4 in the Format dropdown. For what the flag does on FFmpeg's side, check the official FFmpeg documentation.
★ The scope line most people skip. That whole table is introduced with a limit on who it is for: "For best results, and highest compatibility with other WordPress editor blocks (other than the Video or VideoPress block) such as the Cover or Story blocks, we recommend uploading a video with the following specifications". So it is guidance aimed at Cover and Story blocks, not a stated requirement for every upload.
Variations
Shooting at 60 fps. The same cell gives a second figure — "12mbps for 1080p60" — so swap in -b:v 12000k and leave the rest alone.
You do not need to downscale for WordPress. The spec lists a Resolution of "1920×1080 (1080p)" and a Max Resolution of "3840×2160 (4k)", with this note attached to the maximum: "larger is OK, but this is the largest size currently available in the player". Bigger files upload; the player simply tops out.
Trying a container swap first. FFmpeg's documentation describes stream copy as useful "for changing the elementary stream count, container format, or modifying container-level metadata", and adds: "Since there is no decoding or encoding, it is very fast and there is no quality loss." That scope is the catch — stream copy changes the wrapper, never the encoding. If ffmpeg -i input.webm -c copy output.mp4 errors out on your file, the streams inside cannot go into MP4 as they are, and the re-encode above is the answer.
The VP9 sentence, and what it does not say. The recommended settings page carries this: "If you are uploading a video that will only be played in the Video block or shared via VideoPress links, videos encoded with the h.265 or VP9 codecs can be uploaded if desired." Read the limit carefully — it is scoped to videos that will only be played in the Video block or shared via VideoPress links, and it is about codecs. The accepted file types list is about extensions, and .webm is still not on it. No official page addresses that combination, so check the official documentation rather than betting an upload on it.
If you would rather not install FFmpeg
The same conversion runs in a browser tab, which is the path WordPress.com's own troubleshooting line allows for when it mentions "a free online converter":
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
The file is read from disk, converted locally, and handed back — it is never uploaded to a server, which matters when the video is an unpublished course lesson or a client draft. Going the other way for delivery on a self-hosted site, MP4 to WebM is the same tool reversed, and the rest are at all Clapr tools.
Troubleshooting
"This file cannot be processed by the web server." WordPress.com documents this message as a type failure and rules out the first thing everyone tries: "The file type is not supported. This message is not about the file's size." Converting is the fix; compressing is not.
The MP4 uploads, but stalls partway on a big file. That is a different page and a different cause. WordPress.com states, "You can reliably upload files up to 2 GB to your WordPress.com site", and explains the failure mode itself: "A larger file can fail partway through the upload. The larger the file, the longer it takes, and many networks end an upload that runs for too long." Note the word "reliably" — that is not published as a hard cap. VideoPress is documented separately with "The maximum upload size is 6 GB."
The upload button is not there at all. Video upload sits behind a plan, and three official pages state the threshold differently — the Video block page says "Premium plan and above", the accepted file types page says Premium, Business and Commerce, and the VideoPress page says Business and Commerce only. Which one applies depends on the block you are using; see WordPress.com video upload plan requirements.
You are self-hosted and the MP4 is refused on size. The ceiling there comes from PHP, not from WordPress: wp_max_upload_size() is documented as determining "the maximum upload size allowed in php.ini", and returns the smaller of upload_max_filesize and post_max_size. That pair is unpicked in upload_max_filesize vs post_max_size.
FAQ
How do I convert WebM to MP4 for WordPress with FFmpeg?
Re-encode to H.264 video and AAC audio in an MP4 container: ffmpeg -i input.webm -c:v libx264 -b:v 8000k -c:a aac -b:a 160k -movflags +faststart wordpress-video.mp4. Those four choices come from WordPress.com's recommended video settings page.
Why will WordPress not accept my .webm file?
On WordPress.com, .webm is not on the accepted file types list, and that page names it as an extension you would add via a plugin. On a self-hosted site the rules come from core's MIME map instead, which does include webm — so the same file can behave differently on two WordPress sites.
Can I just remux WebM to MP4 without re-encoding? Only if the streams inside are ones MP4 can carry. FFmpeg's stream copy is documented as changing the container, not the encoding, and it guarantees "there is no quality loss" precisely because nothing is decoded. If the copy fails, re-encode.
What bitrate should I use for a WordPress video? WordPress.com recommends "8mbps for 1080p30, 12mbps for 1080p60" and immediately qualifies it with "recommended, but other values are OK". Audio is given as "AAC minimum 160kbps". More on that spec in WordPress recommended video settings.
Will WordPress re-encode my MP4 after I upload it? VideoPress will — its page says uploads are automatically converted "to MP4 format using H.264 video and AAC audio compression". For ordinary Video block uploads, WordPress's official documentation doesn't state this either way.
WordPress quotes above are from the official documentation at wordpress.com/support and developer.wordpress.org, and the stream copy quotes from FFmpeg's official documentation, as recorded on 16 September 2026. These pages are revised regularly — verify against the official documentation before relying on any figure. More command-line write-ups are in our ffmpeg guides, or convert in the browser with WebM to MP4.
