How to resize video to 720p for web streaming
- Step 1Drop your source onto the resizer — Drag in the master —
.mp4,.mov,.mkv,.webm, etc. FFmpeg.wasm runs it locally; nothing uploads. The Free tier handles one file up to 1 GB, plenty for a web-bound clip. - Step 2Set Width to 1280 — Type
1280into Width (px). For a 16:9 source that's a true 720p (1280×720). For a full-width hero that plays on big screens, 1280 is still the recommended baseline; bump to 1920 only if you know visitors view full-screen. - Step 3Keep Lock aspect ratio ON — With Lock on (default), the tool runs
scale=1280:-2:flags=lanczosand derives the height — 720 for a 16:9 source. The-2keeps the height even so H.264 encodes cleanly. - Step 4Run the resize — Process the clip. The output is a 1280×720 MP4 (H.264, CRF 20) with your audio copied. For a typical short web clip this finishes quickly; longer clips scale with duration.
- Step 5Add faststart with the web optimizer — The resizer does NOT add
+faststart, so the moov atom may sit at the end of the file and delay playback start. Run the 720p MP4 through the web optimizer to move the moov atom to the front for instant-play streaming. - Step 6Embed and test on mobile — Drop the optimized 720p MP4 into your CMS, static host, or
<video>tag. Test on a throttled mobile connection — if it still buffers, lower the bitrate with the bitrate setter, or supply a smaller width as a low-bandwidth alternative source.
Pick a web width by player layout
Recommended Width entry for common embed layouts. 1280 (720p) is the default baseline; go up only when visitors view full-screen, down for inline/preview players.
| Player layout | Suggested width | Output (16:9) | Why |
|---|---|---|---|
| Inline article / card player | 854 | 854×480 | Plays in a small box; saves bandwidth |
| Standard embed / blog hero | 1280 | 1280×720 | The 720p sweet spot — sharp and light |
| Full-width landing-page hero | 1280–1920 | up to 1920×1080 | Use 1920 only if full-screen viewing is common |
| Background loop (muted) | 854–1280 | 854×480 to 1280×720 | Lower res is invisible behind text; saves data |
| Mobile-first / low-bandwidth | 640 | 640×360 | Starts fast on cellular; offer as an alt source |
What the resizer does vs what streaming also needs
The resizer handles resolution and a clean encode. Other streaming concerns are handled by sibling tools — the resizer does not do them.
| Streaming need | Resizer handles it? | Where to handle it |
|---|---|---|
| Scale to 720p (1280×720) | Yes | This tool — Width 1280, Lock ON |
| Faststart (moov atom at front) | No | web optimizer |
| Exact bitrate / bandwidth cap | No (CRF only) | bitrate setter |
| Adaptive HLS/DASH ladder | No — single resolution | Encode each rung separately + your packager |
| Different codec (VP9/AV1) for web | No (always H.264) | video transcoder |
Cookbook
Real web-resize runs. The arguments shown are exactly what FFmpeg.wasm executes; the faststart step is a separate tool.
1080p master → 720p web embed + faststart
The standard web flow. Resize to 1280 wide, then add faststart so the player starts immediately. Two tools, two clean steps.
Step 1 (resizer): Width = 1280, Lock ON -vf scale=1280:-2:flags=lanczos -c:v libx264 -crf 20 -c:a copy Output: hero_720.mp4 1280x720 Step 2 (/video-tools/web-optimizer): adds +faststart Output: hero_720_web.mp4 -> instant-play <video> source
Inline card player at 480p
A small in-article player doesn't need 720p. Width 854 produces 480p, which loads faster and looks fine in a card-sized box.
Control: Width = 854, Lock ON Output: 854x480 MP4 Use for inline/card players where the box is small; pair with the web optimizer for faststart.
Background hero loop (muted, low data)
A muted background loop sits behind text — viewers never scrutinise it, so a lower resolution saves real bandwidth without anyone noticing.
Control: Width = 960, Lock ON Output: 960x540 MP4 (audio still copied; mute in the <video> tag) For the smallest possible loop, also drop the bitrate with /video-tools/video-bitrate-set.
Low-bandwidth mobile alternate source
Offer a 360p source alongside the 720p one so phones on cellular get a version that starts instantly. Resize twice at two widths.
720p source: Width = 1280 -> 1280x720 360p source: Width = 640 -> 640x360 Serve both in <video>; the browser/your JS picks per bandwidth. The resizer makes each rung; it does NOT build the ladder for you.
Vertical clip for a mobile web story
A vertical web story uses a 9:16 player. Set the WIDTH to 720 and the height follows (1280) — don't enter 1280 as width for a vertical source.
Input: story.mp4 1080x1920 9:16 Control: Width = 720, Lock ON Output: 720x1280 MP4 -> vertical web-story source Then /video-tools/web-optimizer for faststart.
Edge cases and what actually happens
16:9 source at width 1280 → exactly 1280×720
ExpectedA true 16:9 source scaled to width 1280 with Lock on lands on 720 height via scale=1280:-2. 720 is already even, so there's no rounding drift — this is the canonical 720p web output.
Video doesn't start playing until fully downloaded
Missing faststartThe resizer does not add +faststart, so the moov atom may sit at the end of the MP4, forcing browsers to download the whole file before playback. Run the 720p output through the web optimizer to relocate the moov atom and enable instant streaming.
Need an adaptive HLS/DASH ladder
Not supportedThe resizer outputs a single resolution, not an adaptive-bitrate ladder. For true adaptive streaming, resize the source at several widths (1280, 854, 640) to create each rung, then segment and package them with your own HLS/DASH packager — the resizer just produces the inputs.
Still buffers on mobile after resizing to 720p
Bitrate too highCRF 20 can produce a high bitrate on busy footage even at 720p, which buffers on slow connections. The resizer targets quality, not bandwidth. Constrain the bitrate with the bitrate setter (it uses -maxrate/-bufsize) or offer a 360p alternate source.
Want VP9 or AV1 for the web instead of H.264
Wrong toolThe resizer always outputs H.264 in an MP4. For VP9 (WebM) or AV1 web delivery — smaller files for the same quality — resize for resolution here, then re-encode the codec with the video transcoder.
Full-width hero looks soft at 720p on a 4K monitor
ExpectedA 720p source stretched to fill a 27-inch 4K display will look soft. If full-screen desktop viewing is common for a hero, resize to 1280–1920 instead and accept the larger file — there's a genuine quality/bandwidth trade-off here.
Source already 720p
Re-encode, not resizeDropping a 720p source and setting width 1280 still runs a full CRF 20 pass — it re-encodes. If you only need faststart for the web without scaling, skip the resizer and use the web optimizer directly to avoid an unnecessary quality-costing pass.
Large 4K master over the Free 1 GB cap
1 GB capA long 4K source can exceed 1 GB. Upgrade to Pro (10 GB) or Pro + Media (100 GB), or trim first. The pipeline streams, so there's no duration limit — only the file-size cap.
Frequently asked questions
How do I resize a video to 720p for my website?
Drop the clip onto the resizer, set Width to 1280, and keep Lock aspect ratio on — a 16:9 source becomes 1280×720. Then run the result through the web optimizer to add faststart so it begins playing while it streams. Both run in your browser with no upload.
Why is 720p good for web streaming?
It's the sweet spot: sharp in a typical web player, light on mobile data, and far smaller than a 1080p/4K master most visitors can't fully resolve in an embedded box. Lower bandwidth means faster starts and a smaller hosting bill.
Does the resizer add faststart for instant play?
No — that's the key thing to know. The resizer scales and encodes but does not add +faststart, so the moov atom may sit at the end of the file and delay playback. Run the 720p output through the web optimizer to relocate it to the front.
Can this make an adaptive (HLS/DASH) stream?
No. The resizer outputs one resolution. For adaptive streaming you'd resize the source at several widths (e.g. 1280, 854, 640) to make each quality rung, then segment and package them with an HLS/DASH packager. The resizer produces the inputs, not the manifest.
What width should I pick for an embed?
1280 (720p) is the default baseline. Use 854 (480p) for small inline/card players, 1920 (1080p) only if visitors commonly watch full-screen, and 640 (360p) as a low-bandwidth alternate source. Keep Lock aspect ratio on so height follows.
My 720p video still buffers on phones. What now?
CRF 20 can produce a high bitrate on busy footage even at 720p. The resizer targets quality, not bandwidth. Constrain the bitrate with the bitrate setter, or serve a 360p alternate source for cellular connections.
Can I output WebM/VP9 or AV1 for the web?
Not from the resizer — it always outputs H.264 in MP4. Resize for resolution here, then re-encode the codec with the video transcoder if you want VP9 or AV1 for smaller web files.
Is my footage uploaded?
No. The resize runs entirely in your browser via FFmpeg.wasm. Pre-release product videos or client footage stay on your machine — only an anonymous processed-file counter is recorded for stats.
What format does the resized web video use?
MP4 with H.264 video and your original audio copied. H.264/MP4 is decoded in hardware by every browser and mobile device, which is what you want for smooth, battery-friendly web playback.
Should I serve 720p or 1080p on a full-width hero?
Default to 720p for page speed. If your analytics show a lot of large-desktop, full-screen viewing, resize to 1080p (width 1920) and accept the larger file. Many sites serve 720p plus a 1080p alternate and let the browser/JS choose.
What's the largest source I can resize for web?
Free tier: 1 GB. Pro: 10 GB, up to 5 files. Pro + Media: 100 GB, up to 50 files. Developer: 100 GB unlimited batch. The pipeline streams, so there's no duration cap — only file size.
My web video is vertical — how do I resize it?
Set the WIDTH to the smaller dimension you want (e.g. 720) and keep Lock on; the height follows (1280). Don't enter 1280 as the width for a vertical source or you'll enlarge it. Then add faststart with the web optimizer.
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.