How to compress a video to reduce website bandwidth cost
- Step 1Pick the biggest offenders first — Audit which videos are served most and weigh most. A 50 MB autoplay loop on every landing-page view costs far more egress than a rarely-watched 200 MB explainer. Sort by (size × views) and optimise the top of that list.
- Step 2Drop the source onto Web Optimize — One file per run, up to your tier's size limit (Free 1 GB / Pro 10 GB / Pro + Media 100 GB). MP4, MOV, MKV, and WebM are accepted; output is MP4.
- Step 3Let the fixed recipe do the work — There are no compression sliders — the tool applies 1280px cap + CRF 23 + AAC 128k + faststart. This is the deliberate, defensible default for web; if you need more control, see step 6.
- Step 4Compare input vs output bytes — After the run, note the before/after sizes shown. Multiply the per-file saving by your monthly views to estimate egress reduction. A 60 MB → 15 MB cut at 100k views/month saves ~4.5 TB of transfer.
- Step 5Deploy and re-measure — Replace the file on your CDN/host, purge the cache, and watch your egress dashboard over the next billing cycle. The smaller file also helps Core Web Vitals — see the LCP guide.
- Step 6Need a hard byte budget? Switch tools — If finance gave you a fixed ceiling ("no video over 8 MB"), CRF can't guarantee it. Use video-bitrate-set to target a bitrate, or a size-targeted compressor like discord-compressor / email-compressor which calculate bitrate from a size goal.
Where the egress savings come from
Each lever Web Optimize pulls and its effect on bytes served per view.
| Lever | What it does | Effect on egress |
|---|---|---|
| Width cap 1280px | 1080p/4K source downscaled to ≤1280px wide (Lanczos) | Largest single saving — bytes scale ~with pixel count |
| CRF 23 re-encode | Modern libx264 at constant-quality 23 | 3–5× typical cut vs an over-bitrated source |
| AAC 128k audio | Re-encodes audio to a compact stereo track | Trims a few % to many MB on long videos |
| +faststart | moov to front | No size change, but the smaller file also plays instantly |
CRF (this tool) vs bitrate-target (sibling tools)
Why Web Optimize can't promise an exact file size, and which tool can. Use the right one for your goal.
| Goal | Right tool | Why |
|---|---|---|
| "Good web quality, smaller" | web-optimizer (this tool) | CRF 23 gives consistent quality; size varies with content |
| "Exactly under 8 MB" | video-bitrate-set | Target a video kbps so size = bitrate × duration |
| "Fits a 25 MB upload cap" | discord-compressor | Calculates bitrate from a size target with a safety margin |
| "Half the size, same quality" | h265-encoder | H.265 ~halves bytes vs H.264 at equal quality |
Cookbook
Bandwidth-cost scenarios with the savings math. JAD runs the FFmpeg equivalent in your browser.
Autoplay hero loop: 60 MB → ~15 MB
An autoplay background loop is served on every landing-page view, so its size is multiplied by your busiest page's traffic. Cutting it 4× is the single highest-leverage egress fix on most marketing sites.
Before: hero-loop.mp4 · 1920x1080 · 60 MB After (Web Optimize): 1280x720 · CRF 23 · ~15 MB Egress at 100,000 views/month: Before: 60 MB × 100k = ~6.0 TB After: 15 MB × 100k = ~1.5 TB Saved: ~4.5 TB/month
The recipe (constant-quality, content-dependent size)
This is what runs in-browser. Note CRF 23 is quality-locked, so the output bytes depend on the footage.
ffmpeg -i product.mp4 \ -vf "scale='min(1280,iw)':-2:flags=lanczos" \ -c:v libx264 -preset medium -crf 23 -pix_fmt yuv420p \ -c:a aac -b:a 128k -movflags +faststart \ product-web.mp4 # Output size = depends on motion/grain at CRF 23
Grainy footage barely shrinks — switch to a bitrate cap
Film-grain and confetti force CRF 23 to spend a lot of bits, so the size cut is small. If your budget is fixed, target a bitrate instead of quality.
Web Optimize on a grainy 1080p clip: 40 MB → 33 MB (only ~18% saved — grain is expensive) Need it under 12 MB for a 60s clip? Use video-bitrate-set: videoKbps ≈ (12 MB × 8) / 60s − 128 ≈ 1,470 kbps → /video-tools/video-bitrate-set
Want maximum savings? H.265 after Web Optimize sizing
H.264 maximises compatibility; H.265 roughly halves bytes at equal quality if your audience's browsers support it. For cost-sensitive, modern-audience delivery, encode to H.265 with the sibling tool.
H.264 (Web Optimize): 1280x720 · ~15 MB · plays everywhere H.265 (h265-encoder): 1280x720 · ~8 MB · needs HEVC support → /video-tools/h265-encoder (Trade smaller bytes for narrower browser support.)
Batch the masters, then serve the small ones
You can run a big master through Web Optimize (up to 100 GB on Pro + Media) and serve only the slim output. The heavy source never touches your CDN.
master.mov · 8 GB (ProRes) → Web Optimize → serve-me.mp4 · 1280x720 H.264 · ~120 MB The 8 GB master stays on your machine; only the 120 MB web file is uploaded and served.
Edge cases and what actually happens
You need an exact file-size ceiling
Use a different toolWeb Optimize uses CRF 23 (constant quality), so it cannot guarantee "under N MB." Size varies with the footage. For a hard byte budget use video-bitrate-set (target kbps) or discord-compressor/email-compressor (calculate bitrate from a size target).
Grainy or high-motion footage barely shrinks
ExpectedCRF spends more bits where the picture is harder to compress — grain, noise, confetti, fast camera pans. At CRF 23 those clips stay relatively large. That's correct quality behaviour, not a bug. To force a smaller file, target a bitrate and accept some quality loss on the busy frames.
Source already small and well-compressed
Little to gainIf the input is already 1280px wide and lightly encoded, Web Optimize has little headroom — the output may be close to the input size or slightly larger, since CRF 23 re-encode of an already-efficient file can't reclaim much. Check before/after bytes; if there's no win, the source was already web-ready.
H.265 would save more but you used Web Optimize
By designWeb Optimize always outputs H.264 for maximum compatibility. H.265/HEVC roughly halves bytes at equal quality but isn't decodable by every browser. If your audience supports HEVC and bandwidth cost dominates compatibility, use h265-encoder instead — that's a deliberate trade.
Audio-heavy file dominated by the audio track
Partial savingOn a long, low-motion video (e.g. a webinar), the AAC 128k audio can become a large share of the output. Web Optimize doesn't let you lower audio bitrate. If audio dominates, audio-track-extractor plus a separate re-mux, or a bitrate-set pass, gives finer control.
4K master on mobile fails with OOM
OOM on mobileDecoding 4K plus libx264 can exhaust the mobile WebAssembly heap (Aborted(OOM)). Run large masters on desktop where the heap is bigger, or downscale/trim first. Desktop browsers handle multi-GB sources well within the tier limits.
File over the tier size limit
RejectedFree caps at 1 GB, Pro at 10 GB, Pro + Media at 100 GB. A raw 4K or ProRes master can exceed Free easily. Upgrade, or trim with lossless-trimmer first. Note the limit is bytes, not minutes — duration is unbounded.
Multiple videos to compress
Single file onlyWeb Optimize processes one file per run. There's no batch queue. For a library, run them sequentially. The size win per file is consistent, so the total egress saving still adds up across the set.
Re-compressing an already-compressed web file
Quality erodesEach lossy re-encode loses a little quality (generation loss). Running Web Optimize on a file that was already CRF-encoded saves few bytes and softens the picture. Always optimise from the highest-quality master you have, not from a previously-compressed copy.
Egress didn't drop after deploying
Check cacheIf your CDN cached the old large file, viewers keep getting it until the cache expires or is purged. Replace the file, purge/invalidate the CDN cache, and confirm the Content-Length of the served file dropped. The compression worked; the cache was serving stale bytes.
Frequently asked questions
How much will Web Optimize shrink my video?
For a typical 1080p source served at original size, expect roughly 3–5× smaller after the 1280px cap + CRF 23 re-encode. Exact savings depend on the footage — calm, low-motion video compresses far more than grainy or high-motion footage, because CRF 23 holds quality constant and lets size float.
Can I compress to an exact file size?
Not with this tool — it uses CRF 23 (constant quality), so size varies with content. For a hard ceiling like "under 8 MB," use video-bitrate-set to target a bitrate (size ≈ bitrate × duration) or a size-targeted compressor such as discord-compressor.
Will compression hurt quality?
CRF 23 is widely considered visually transparent for web delivery — most viewers won't see a difference at typical playback sizes. The bigger visible change is the 1280px width cap, which only matters if you were displaying the video larger than 1280px wide. For most placements, the quality is indistinguishable and the savings are real.
Does it lower CDN bandwidth cost directly?
Yes — egress is billed per byte transferred, so a smaller file means fewer bytes per view and a proportionally smaller bill. Multiply the per-file saving by monthly views to estimate it. Just remember to purge your CDN cache so viewers actually receive the smaller file.
Would H.265 save even more?
Yes — H.265/HEVC roughly halves bytes at equal quality compared to H.264. But it isn't decodable by every browser. Web Optimize sticks to H.264 for universal compatibility. If your audience supports HEVC and cost is the priority, use h265-encoder.
Can I lower the audio bitrate to save more?
Not in Web Optimize — audio is fixed at AAC 128k. On audio-dominated content (webinars, podcasts-with-video) that can be a meaningful share of the file. For finer audio control, extract and re-mux with audio-track-extractor or use a bitrate-set workflow.
Is there a fee per video processed?
No. Compression runs entirely in your browser via FFmpeg.wasm — there's no per-file processing fee and no upload (so you don't pay egress to send the file anywhere either). Tier pricing only gates the maximum file size, not a per-run charge.
How big a source can I compress?
Free up to 1 GB, Pro up to 10 GB, Pro + Media up to 100 GB. You can run a big master locally and serve only the small output. The limit is file size, not duration — long videos are fine as long as the file fits the cap.
Should I compress from the master or the web copy?
Always from the highest-quality master. Re-compressing an already-compressed file adds generation loss for little extra saving. Keep your master, run Web Optimize once, and serve that output.
Why didn't my bandwidth drop after I deployed?
Almost always CDN caching — the edge is still serving the old large file. Replace the file, purge/invalidate the cache, and verify the served Content-Length shrank. The compression is correct; the cache was stale.
Does the smaller file also load faster for users?
Yes — fewer bytes means a quicker download, and because Web Optimize also sets +faststart, playback begins before the full file arrives. That helps both perceived speed and Core Web Vitals; see the LCP guide.
Can I batch a whole video library at once?
Web Optimize handles one file per run, so process them sequentially. There's no drag-and-drop batch queue. For each file the saving is consistent, so the cumulative egress reduction across a library is substantial.
Privacy first
Every JAD Video tool runs entirely in your browser via WebCodecs and FFmpeg (WebAssembly). Your video files never leave your device — verified by zero outbound network requests during processing.