The Webflow video size limit isn't your plan. It's 30 MB, flat.

You exported a hero loop, dragged it into Webflow, and got either a hard rejection or a background video that looks noticeably softer on the live site than it did in your editor. Raising the export quality makes the first problem worse and does nothing for the second.

Quick answer: The Webflow video size limit is 10 MB for a single asset upload and 30 MB for the Background Video component, and it is the same on every plan. Encode the clip to 1280x720 at 24 to 30 fps with the audio track stripped and it will fit, since a 4,000 kbps 720p encode buys you about 60 seconds inside 30 MB. To run that encode over a whole folder of clips without installing FFmpeg anywhere, send each file to FFmpeg Micro as one API call and get the compressed MP4 back.

Neither Webflow cap can be raised by upgrading

Both Webflow limits are platform-wide, not plan-gated. The Assets panel rejects any single file over 10 MB, and the Background Video component tops out at 30 MB, whether the site is on Basic, CMS, Business, or Enterprise. The support threads asking whether the background video cap can be increased all end the same way, because there is no toggle to flip.

That matters for how you frame the work. You are not negotiating with a quota, you are hitting a fixed target file size. Target-size encoding is a solved problem in FFmpeg, and once you accept the number as fixed the whole task collapses into arithmetic plus one command.

Webflow re-encodes background video to 720p regardless of what you upload

Here is the part that explains the blur. When you upload an MP4 to the Background Video component, Webflow transcodes it server-side into a WebM and an MP4 pair capped at 720p, and it serves those derivatives to visitors. Your pristine 4K master is never what loads in the browser.

So the loop people get stuck in is: the video looks soft, they re-export at a higher bitrate, the file gets closer to 30 MB, and the site looks exactly the same. The output quality is set by Webflow's encoder, and the only variable you control is what that encoder receives.

Feed it a file that already matches its output shape and you stop losing a generation of quality to a downscale you did not ask for. That means 1280x720 (or 1920x1080 if you want headroom), a locked frame rate, and a clean h.264 encode. It is the same principle as YouTube Shorts video settings that survive the re-encode: match the platform's target so its transcoder has nothing left to do.

Target-size math: what actually fits in 30 MB

The bitrate that fits a given file size is a division, not a guess. Multiply the target size in megabytes by 8,192 to get kilobits, then divide by the clip length in seconds. A 24 MB target over a 20-second loop is 24 × 8192 / 20 = 9,830 kbps, which is far more bitrate than a 720p loop needs.

Run it the other way and the practical picture gets clearer.

Leave 15 percent of headroom, because container overhead and Webflow's own byte accounting will not match your ls -lh output exactly. The takeaway is that a 6 to 12 second hero loop, which is what most sites use, is nowhere near the cap once it is 720p and silent. Sites that blow through 30 MB are almost always uploading a 4K master or a 45-second clip that nobody watches past the first loop anyway.

The encode: one command per clip

For a hero loop, constant-quality encoding beats chasing an exact byte count. This command downscales to 720p, locks the frame rate, drops audio entirely, and writes a browser-safe MP4:

ffmpeg -i hero-master.mov \
  -an -vf "scale=1280:-2,fps=30" \
  -c:v libx264 -crf 26 -preset slow \
  -profile:v high -pix_fmt yuv420p \
  -movflags +faststart \
  hero-webflow.mp4

A 10-second 4K source typically lands between 2 and 5 MB out of that, comfortably under both caps. -an is doing real work: background video autoplays muted, so every kilobit spent on an audio track is wasted. -pix_fmt yuv420p and -profile:v high keep Safari happy, which is covered in more depth in MP4 not playing in browser? Four encoder flags fix it.

When the clip is long enough that CRF overshoots, switch to two-pass with the bitrate you calculated above:

ffmpeg -y -i hero-master.mov -an -vf "scale=1280:-2,fps=30" \
  -c:v libx264 -b:v 3800k -pass 1 -preset slow -f mp4 /dev/null

ffmpeg -i hero-master.mov -an -vf "scale=1280:-2,fps=30" \
  -c:v libx264 -b:v 3800k -pass 2 -preset slow \
  -pix_fmt yuv420p -movflags +faststart hero-webflow.mp4

Two-pass hits the target within a few percent because the encoder gets to see the whole clip before deciding where to spend bits. Single-pass CRF cannot do that, which is why long clips with a busy section in the middle come out larger than expected.

The escape hatch for anything over 30 MB: host the file yourself

If the video genuinely needs to be 90 seconds or 1080p at high bitrate, stop fighting the Background Video component and serve the file from your own storage instead. Webflow will happily play a <video> element pointing at an external URL, and nothing about that path is size-capped.

<video autoplay loop muted playsinline preload="auto"
       poster="https://cdn.example.com/hero-poster.jpg"
       style="width:100%;height:100%;object-fit:cover">
  <source src="https://cdn.example.com/hero.webm" type="video/webm">
  <source src="https://cdn.example.com/hero.mp4" type="video/mp4">
</video>

Both muted and playsinline are required or iOS Safari will refuse to autoplay and show a play button on top of your hero. The WebM source goes first so Chrome and Firefox take the smaller file, and Safari falls through to the MP4. You also get a poster frame, which the native component does not give you.

Doing a whole site's worth of clips at once

A redesign rarely involves one video. It is a hero loop, three section backgrounds, six case study clips, and a set of CMS items that each need their own file under 10 MB. Running the command by hand 20 times is where this stops being fun.

The shell version is a loop over a folder:

mkdir -p out
for f in clips/*.mov; do
  ffmpeg -i "$f" -an -vf "scale=1280:-2,fps=30" \
    -c:v libx264 -crf 26 -preset slow \
    -profile:v high -pix_fmt yuv420p -movflags +faststart \
    "out/$(basename "${f%.*}")-webflow.mp4"
done
ls -lS out/

That ls -lS sorts largest first, so you can see instantly whether anything is still over the cap and needs a two-pass rerun at a lower bitrate.

If you would rather not keep an FFmpeg build current on every machine that touches the marketing site, this is exactly the job FFmpeg Micro exists for. Point it at each source URL with the same encode settings, take a webhook when the MP4 is ready, and the bytes never move through your laptop or your CI runner. There is a free tier, and you can try the encode on one clip in the playground before wiring up the batch. The same call works from n8n, Make, or Zapier if the clips arrive from a Drive folder or a client intake form.

Pitfalls that cost people an afternoon

The most common one is re-uploading a higher quality file to fix a soft background video. Webflow's 720p re-encode is the source of the softness, so a bigger upload changes nothing except how long the upload takes. Encode to 720p yourself and the result gets sharper, not blurrier, because the downscale happens once with your settings instead of twice with theirs.

Screen recordings and phone footage often carry a variable frame rate, and a VFR source pushed through a bitrate target produces wildly unpredictable file sizes. The fps=30 filter in the commands above normalizes that. Add -vsync cfr if timestamps are still drifting.

Watch the scale filter divisor. scale=1280:-1 will produce an odd height on some sources, and libx264 with yuv420p rejects odd dimensions outright. -2 rounds to the nearest even number and avoids the failure entirely.

iPhone footage shot in HDR comes out gray and washed after a naive re-encode, and Webflow's transcoder will not fix it for you. Tone-map before you upload, which is walked through in FFmpeg HDR to SDR: stop iPhone uploads coming out gray.

Finally, remember which cap you are actually under. Dropping a <video> element into an HTML Embed and pointing it at a file you uploaded through the Assets panel puts you under the 10 MB asset limit, not the 30 MB background video limit. The 30 MB allowance only applies to the Background Video component.

FAQ

Can the Webflow background video size limit be increased?

The 30 MB background video limit cannot be increased on any Webflow plan, and upgrading to Business or Enterprise does not change it. The only way past it is to host the file outside Webflow and reference it from a <video> element in an HTML Embed.

Why does my background video look blurry after uploading to Webflow?

Webflow re-encodes every background video server-side into a 720p WebM and MP4 pair and serves those to visitors, so a 4K upload is downscaled before anyone sees it. Uploading a cleaner 1280x720 file gives Webflow's encoder less to change and produces a sharper result than uploading a larger master.

How do I compress a video to under 10 MB for Webflow?

Strip the audio, scale to 1280x720, lock the frame rate, and encode with ffmpeg -i in.mp4 -an -vf "scale=1280:-2,fps=30" -c:v libx264 -crf 26 -preset slow -pix_fmt yuv420p -movflags +faststart out.mp4. Raise the CRF value toward 30 if the result is still over 10 MB, since each step up cuts the file size roughly 15 to 20 percent.

Can I use a video longer than 30 seconds as a Webflow background video?

A clip longer than 30 seconds fits inside the 30 MB cap as long as the bitrate is low enough, and 720p at 2,500 kbps gives you about 98 seconds. Past that, host the file on S3 or R2 and embed it, because pushing the bitrate lower to fit will visibly damage any footage with motion in it.

Should I upload MP4 or WebM to Webflow?

Upload MP4 to the Background Video component, since that is the format it accepts and it generates the WebM derivative itself. Encode both an MP4 and a VP9 WebM only when you are self-hosting the file and writing your own <video> tag with two sources.

Encode one hero loop with the CRF command above and check the file size before you touch the rest of the site. When it works and you want the same settings applied to the whole folder without installing anything, sign up free and run it as an API call instead.