FFmpeg: Compress Video for WordPress to the Official Spec

Every number in the command below comes from one place: the table WordPress.com publishes under "Video specifications". Not from a forum thread, not from what usually looks fine — from the official recommended video settings, row by row.

That matters because the table also tells you how firmly to hold each value, and the qualifiers get dropped in almost every copy of it. Here is the command, then each flag traced back to the row it is carrying.

The command

ffmpeg -i input.mov -vf scale=-2:1080 -c:v libx264 -b:v 8M \
  -c:a aac -b:a 160k -movflags +faststart output.mp4

Before you run it, read the sentence that introduces the table it is built from:

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

Two things in that sentence change how you should treat the settings. It is about compatibility with blocks other than the Video or VideoPress block — the Cover and Story blocks are the ones named. And it says "we recommend", which the bit rate row then reinforces in writing.

What each flag does

Each line of the command exists because a row of WordPress.com's table asks for it. The right-hand column is the table's own wording, quoted:

Three details worth pulling out of that table:

The bit rate is annotated, in the official table itself, "recommended, but other values are OK". So -b:v 8M is a documented starting point, not a requirement you have to hit. If your footage is a static screen recording and 3M looks identical, WordPress.com's own page has already told you that is acceptable.

The audio row says "minimum". 160kbps is a floor in that wording, not a target — which is the opposite of how the video row reads.

The last row is a container layout, not a quality setting. WordPress.com describes the goal in the same cell: "so the whole file doesn't need to be downloaded before playback can begin". For what -movflags +faststart does on FFmpeg's side, and for the exact option names in your build, check the official FFmpeg documentation.

Note also what the table does not contain: any CRF value, any encoder preset, any two-pass instruction. WordPress.com expresses quality as a bit rate and nothing else, which is why this command does too. If you prefer a quality-based mode, take the values from the official FFmpeg documentation for your encoder — WordPress.com publishes none.

Variations

Shooting 60fps. The same row covers it: "12mbps for 1080p60". Change one flag to -b:v 12M and leave the rest alone.

You want to upload 4K. The table's Max Resolution row is "3840×2160 (4k)", annotated "larger is OK, but this is the largest size currently available in the player". Read that literally — a larger file is not rejected, the player simply tops out there.

H.265 or VP9 instead of H.264. Allowed, but only in a documented narrow case: "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." That "only be played in the Video block or shared via VideoPress links" is the whole condition. Drop it and you have turned a conditional sentence into a false one.

You would rather not install FFmpeg. WordPress.com's own suggestion here is a GUI: "If your source video doesn't meet the above specifications, a tool like HandBrake can be used to convert it before you upload it to the Media Library," with the advice to "Select a "Preset" (e.g., Fast 1080p30 or HQ 1080p30: HQ presets will be slower but will produce better results)." A browser-based encoder does the same job without an install:

That runs in the tab — the file is read from disk, re-encoded locally and handed back, never uploaded to a server. For manual control over resolution and bitrate rather than a preset, the video compressor exposes them, and the rest of the set is at all Clapr tools. More command breakdowns live in the FFmpeg guides hub.

Troubleshooting

The file matches the spec and the upload still fails (self-hosted). The spec table has nothing to do with your size ceiling. On a self-hosted install the number shown in the admin is, in WordPress's words, "maximum upload size for files, as set by your hosting provider" — WordPress core computes it from php.ini as the smaller of upload_max_filesize and post_max_size. The official PHP guidance adds a warning worth reading before you email your host: "Bear in mind that on shared hosting accounts, those limits are usually set on a server level and you may not be able to modify them or increase them above a certain value." Details in maximum upload file size in WordPress.

The upload dies partway through. Two different PHP directives are involved, and most write-ups only mention one. The documentation identifies max_input_time as the relevant one: "It is usually used to limit the amount of time allowed to upload files. It's important to note that the amount of time is separate from max_execution_time."

You get "This file cannot be processed by the web server." WordPress.com's own explanation closes off the obvious guess: "The file type is not supported. This message is not about the file's size." Re-encoding smaller will not help; the container or extension is the problem.

You are on WordPress.com and the file is large. The documented figures are "You can reliably upload files up to 2 GB" for ordinary uploads, and "The maximum upload size is 6 GB" for VideoPress. Note the word reliably in the first one — it is a stated expectation, not a published hard cap. One reassuring line, rarely quoted: "Failed attempts don't count against your storage space limit." The 6 GB figure comes with a plan condition, though — see the VideoPress upload size limit.

The encode is fine but the block will not let you upload (WordPress.com). Then it is a plan question, not an encoding one, and the bar depends on which block you use. "The Video block is available on the Premium plan and above," while VideoPress "is available on sites with the WordPress.com Business and Commerce plans. For free sites and sites on the Personal and Premium plans, upgrade your plan to access this feature." No bitrate change gets around that.

FAQ

Do I have to use 8 mbps for WordPress? No. The bit rate row is annotated in WordPress.com's own table as "recommended, but other values are OK". It is a documented default, not a gate.

Should I use CRF instead of a fixed bitrate? WordPress.com's table has no CRF, preset or two-pass row, so there is no official value to match. If you want a quality-based mode, take the numbers from the official FFmpeg documentation for your encoder and confirm them against your own build.

Does this table apply to every video I upload? Read its scope sentence: it is for "highest compatibility with other WordPress editor blocks (other than the Video or VideoPress block) such as the Cover or Story blocks." A Cover block background video is exactly the case it was written for. For a full walkthrough of the table, see WordPress recommended video settings.

If VideoPress re-encodes my upload anyway, why compress first? VideoPress does convert: "When you upload a video, VideoPress automatically converts it to MP4 format using H.264 video and AAC audio compression." But the same page also says "Videos that are smaller or compressed will load faster for your viewers," and a smaller source still uploads faster and consumes less of your plan's storage. What VideoPress outputs beyond MP4, H.264 and AAC — bitrates, resolution ladder — is not published.

Can I just upload WebM to skip the H.264 encode? It depends which WordPress you are on, and the two official lists disagree. See WebM uploads on WordPress for both sides.

Specifications cited from WordPress.com's Recommended video settings, VideoPress and Accepted file types, plus the PHP Optimization handbook, checked 16 September 2026. Verify against the official pages before relying on them.