WordPress names the result it wants out loud — "Fast Start / Web Optimized / progressive download" — and then stops there: it publishes no FFmpeg commands at all. Most write-ups about -movflags +faststart talk about "optimizing for the web" in the abstract. WordPress.com actually wrote its requirement down, twice, on two unrelated pages — that is what this page covers. For what the flag itself does, check the official FFmpeg documentation.
The command
ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4-c copy writes the audio and video streams into the new file without decoding or encoding them. No re-encode, so no generation loss and no waiting on an encoder.
Where WordPress asks for this, in its own words
The first place is the recommended video settings table. Its last row reads, verbatim:
Other Settings Fast Start / Web Optimized / progressive download (so the whole file doesn't need to be downloaded before playback can begin)The parenthetical is the useful half. WordPress is not asking for a vague optimization — it is describing a playback behaviour: viewers should not have to wait for the full download before the video starts.
The second place is the VideoPress documentation, which describes the same behaviour from the hosting side:
"All videos are optimized for progressive loading, so viewers can start watching while the video continues to download. Videos that are smaller or compressed will load faster for your viewers."
Two separate official pages, one idea. That is worth noticing, because it tells you which path already does this for you and which one does not. VideoPress states it does. But VideoPress is gated: "This feature 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." Outside that path, the recommended settings table puts the job back on your export — which is where FFmpeg comes in.
One qualifier you must keep attached to that table, because it is printed on the page: it applies "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." So the spec is aimed at blocks like Cover — the one that "lets you add a background color, image or video with a text overlay" — not at uploads in general.
What each flag does
-i input.mp4— the source file.-c copy— stream copy. FFmpeg's documentation describes the scope directly: "Streamcopy is useful for changing the elementary stream count, container format, or modifying container-level metadata. Since there is no decoding or encoding, it is very fast and there is no quality loss." Note the scope FFmpeg gives it: stream count, container format, container-level metadata — not resolution, not bit rate, not filters.-movflags +faststart— the part this page is about. WordPress names the result it wants ("Fast Start / Web Optimized / progressive download") and stops there; it publishes no FFmpeg commands at all. For FFmpeg's own description of this flag and the rest of the MP4 muxer options, check the official FFmpeg documentation rather than a blog assertion.output.mp4— write to a new file. Do not point the output at the input path.
Variations
Re-encoding anyway? Put the flag on the same command and hit the published spec while you are there. The recommended table gives 1920×1080 (1080p) for resolution, h.264 for format, "8mbps for 1080p30, 12mbps for 1080p60" for bit rate, and "AAC minimum 160kbps" for audio:
ffmpeg -i input.mov -c:v libx264 -b:v 8M -s 1920x1080 \
-c:a aac -b:a 160k -movflags +faststart output.mp4Read the bit rate row literally before you treat those numbers as rules: WordPress annotates them "recommended, but other values are OK", and the audio row says minimum 160kbps, so higher is still inside the recommendation.
Going bigger than 1080p? The Max Resolution row is 3840×2160 (4k) with the note "larger is OK, but this is the largest size currently available in the player." That is a player ceiling, not an upload gate.
H.265 or VP9? Allowed, but only under a stated condition: "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." Drop that clause and you have invented a general claim WordPress never made.
No FFmpeg, no command line? WordPress's own suggestion 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." Its instructions for it are two lines — "Ensure "MP4" is selected in the "Format" dropdown, and "Web Optimized" is checked." That checkbox is the same requirement as the last row of the table.
If the real problem is size, not layout
File size is what actually stops most WordPress uploads. WordPress.com's first piece of advice when a large file will not upload is "Compress the file to reduce its size, then upload it again", and the VideoPress page adds that "Videos that are smaller or compressed will load faster for your viewers."
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
This runs in your browser tab — the file is read from disk, re-encoded locally, and handed back, so nothing is uploaded on the way to fixing an upload. For the underlying numbers, see WordPress's recommended video settings; if the file is a QuickTime export, MOV to MP4 handles the container swap. The rest of the set lives in all Clapr tools.
Troubleshooting
The upload is rejected with "This file cannot be processed by the web server." Faststart is not the cure. WordPress.com's explanation is explicit: "The file type is not supported. This message is not about the file's size." Its own remedy is to "convert them to a valid file type before uploading."
Self-hosted, and the editor says "Sorry, this file type is not supported here." Same category of problem — the extension, not the byte layout.
The upload dies partway through on a big file. Look at the PHP timeouts. WordPress documents that max_input_time "is usually used to limit the amount of time allowed to upload files", and that it "is separate from max_execution_time". Most advice online only mentions the second one.
A VideoPress upload failed and you are worried it burned storage. It did not. The official wording is blunt: "Failed attempts don't count against your storage space limit." The same page names the usual culprit — "a slow or unreliable internet connection can limit the size of your video upload" — and suggests retrying "at a different time of day or from a computer with a faster internet connection."
Playback still starts slowly for visitors. Check the block's Preload setting before re-muxing again. The Video block documentation lists three settings, and describes None as: "Nothing about the video file is downloaded automatically. The download of the video file only begins when your visitor clicks the Play button. This is the fastest setting."
FAQ
Does WordPress require faststart? It appears in a table introduced as what WordPress recommends "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." That is a recommendation with a stated scope, not a documented upload gate.
Does -c copy re-encode anything?
No. FFmpeg documents stream copy as useful for "changing the elementary stream count, container format, or modifying container-level metadata", and says that because "there is no decoding or encoding, it is very fast and there is no quality loss".
Does VideoPress already do this for me? Its documentation says "All videos are optimized for progressive loading" and that on upload it "automatically converts it to MP4 format using H.264 video and AAC audio compression". Note the plan condition: VideoPress is documented as available on the Business and Commerce plans.
Does a self-hosted WordPress site re-encode my video? WordPress's official documentation does not state this either way. Transcoding is documented for VideoPress only; for any other path, check the official documentation rather than assuming a behaviour in either direction. See WordPress video file too large to upload for the size side of uploads.
Will a Fast Start file load faster? WordPress states two separate things here. The benefit it puts next to Fast Start is in its own parenthetical: the whole file "doesn't need to be downloaded before playback can begin." For load time itself it points at size — "Videos that are smaller or compressed will load faster for your viewers."
All WordPress quotes are from the official WordPress.com support pages (recommended video settings, VideoPress, accepted file types, troubleshooting uploads) and developer.wordpress.org (PHP optimization, Video block), checked 16 September 2026; the stream copy quote is from the FFmpeg documentation. These pages change — verify before relying on them. More command-line write-ups live in our ffmpeg guides.
