Convert MP4 to WebM for the Web: Smaller Files, Faster Pages, No Upload Required

WebM vs MP4: What's Actually Different?

WebM is a royalty-free container built specifically for web delivery. MP4 is a general-purpose container designed for broad compatibility. The practical difference is not really about containers: it is about the codecs they carry.

• MP4 typically carries H.264 (AVC) video and AAC audio. H.264 is the universal fallback: every browser on every platform plays it, which is exactly why it is the right choice for email attachments, social uploads, and anywhere you do not control the player.
• WebM carries VP8, VP9, or AV1 video alongside Opus or Vorbis audio. VP9 is the practical choice for most web projects today: near-universal modern browser support, roughly 30–50% smaller files than H.264 at similar perceived quality, and encode times measured in seconds for typical web clips.
• AV1 in WebM pushes compression further still — typically 40–55% smaller than H.264 — but encode times are 5–10x longer than VP9, and hardware decoder support on pre-2020 mobile devices is inconsistent.

The reason web developers care about this split: H.264 is royalty-bearing, which means tooling and distribution can carry licensing costs and complications. VP9 and AV1 are royalty-free, which is why they are the codecs of choice when you are serving video you control directly.

Browser Support in 2026: What You Can Safely Ship

VP9 in WebM is the safe bet for modern web delivery. WebM (VP8/VP9) is supported in current versions of all major desktop and mobile browsers — Chrome, Edge, Firefox, and Safari all handle it. The practical implication: if you serve WebM/VP9 alongside an MP4/H.264 fallback, you get maximum compression for modern browsers and guaranteed compatibility for anything older.

The Safari situation has improved materially. Safari historically lagged on VP9 and AV1 support, forcing many teams to maintain MP4 as the primary format. That has changed:

• VP8/VP9 in WebM: supported in current Safari versions.
• AV1: supported in Safari 17 and later, alongside Chrome, Firefox, and Edge.

This means AV1 is a viable choice if your audience skews toward recent hardware and software, though it remains a stretch if you need to cover pre-2022 mobile browsers. For most projects, VP9 WebM plus H.264 MP4 fallback covers 99%+ of users.

H.264 in MP4 remains the most broadly compatible format across all browsers, making it the correct fallback — not the primary format for a performance-optimised site.

How Much Smaller? VP9 and AV1 File Size Benchmarks

The numbers here come from several independent benchmarks and are consistent enough to use as planning figures.

1080p 60-second clip, comparative output sizes:

720p 60-second clip:

These are representative benchmarks. Mux's encoding guidance recommends 2–3 Mbps for 1080p VP9 versus 4–6 Mbps for H.264 at comparable quality — implying roughly 40–50% bitrate savings.

The rule of thumb for planning: expect WebM/VP9 to deliver 30–50% smaller files than MP4/H.264 at equivalent visual quality. AV1 can push that to 40–58%, at the cost of significantly longer encode times.

The <video> Fallback Pattern Every Site Should Use

Serving WebM without a fallback is a mistake — older browsers and some contexts still require MP4. The correct pattern is a <video> element with multiple <source> children in priority order. The browser picks the first source it can play and stops evaluating the rest.

<video
  autoplay
  muted
  loop
  playsinline
  preload="metadata"
  poster="/images/video-poster.jpg"
  width="1280"
  height="720"
>
  <source src="/video/hero.webm" type='video/webm; codecs="vp9, opus"' />
  <source src="/video/hero.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"' />
  <p>Your browser doesn't support HTML video. <a href="/video/hero.mp4">Download the video</a>.</p>
</video>

A few implementation notes worth keeping in mind:

Order matters

Put the WebM source first. Browsers that support VP9 will take it and download the smaller file. Browsers that do not will fall through to the MP4. MDN explicitly recommends listing the smaller resource first so capable browsers pay the lower bandwidth cost.

Include the type attribute with codec hints

The browser uses this to skip sources it cannot play without attempting to download them. video/webm; codecs="vp9, opus" and video/mp4; codecs="avc1.42E01E, mp4a.40.2" are the correct type strings for VP9 WebM and H.264 MP4 respectively.

preload="metadata" instead of preload="auto"

This tells the browser to fetch only enough to know the video's duration and dimensions, not the full file, on initial load. For hero videos especially, this is the difference between video content dominating your LCP or staying out of the critical path.

muted is required for autoplay

Browsers block autoplay of unmuted video. If you want a background loop to start automatically, it must be muted.

playsinline for iOS Safari

Without this, iOS Safari will try to play the video fullscreen rather than inline in the page.

Video Format Choices and Core Web Vitals

Converting MP4 to WebM is not just about file size. It connects directly to how Google scores your page.

Images and video account for over 70% of the bytes downloaded for the average website. Choosing more efficient formats can lead to lower overall page load times and potentially improve a page's Largest Contentful Paint (LCP). LCP is one of the three Core Web Vitals Google uses in ranking — it measures how long the largest visible element (often a hero image or video) takes to render.

When your hero video is the LCP element, every megabyte you strip from it reduces LCP time directly. Switching a 12 MB H.264 hero to a 7 MB VP9 WebM, combined with preload="metadata" and a poster image, is one of the higher-leverage LCP optimisations available on video-heavy pages.

The pattern that works:

1. Serve WebM/VP9 as the primary source, MP4/H.264 as fallback.
2. Use preload="metadata" to avoid blocking the initial parse on a full video download.
3. Set a poster image that renders while the video loads, so the LCP element itself is a small static image rather than waiting for the first video frame.
4. For below-the-fold video: consider preload="none" and an IntersectionObserver to defer loading until the element is near the viewport.

If you are already optimising images for web performance — converting to WebP or AVIF, setting responsive sizes, preloading the hero — video format is the next logical step. See Optimising Hero Images for Web Performance for the image side of this and how image and video optimisation work together for LCP-critical pages.

Why Online Converters Are a Privacy Risk

The obvious tool for converting MP4 to WebM is a search away — dozens of sites offer free browser-based conversion. But what most of them actually do is upload your file to a remote server, run FFmpeg, and hand you back the result. That means your footage leaves your machine.

The implications range from inconvenient to serious.

Retention windows vary wildly

Some services delete files after conversion; others hold them for 24 hours or longer. Convertio's policy, for example, states that output files are held for 24 hours before deletion, with IP addresses and conversion metadata kept for significantly longer. If you are converting client footage, demo reels, unreleased product videos, or anything under NDA, "deleted after 24 hours" is not the same as "never left your device."

Logs persist even when files do not

Even services that delete files promptly tend to log IP addresses, file types, conversion timestamps, and success flags. This data can be retained for weeks or months, and it is exactly the kind of data that appears in breach reports.

Real incidents have happened

A 2024 report documented a breach at TuneFab, a media converter, where a misconfigured database exposed around 280 GB of user data including IP addresses and account identifiers. A separate incident involved Dirpy, an online video downloader, leaking 15.7 million records including user activity logs and the URLs of downloaded content.

The alternative is browser-based conversion using WebAssembly — tools where the conversion engine runs inside your browser tab and your video bytes never touch a remote server. ffmpeg.wasm is a full WebAssembly port of FFmpeg that runs entirely client-side; the project explicitly describes its privacy benefit as "your users' data only lives inside their browser." These tools can even run offline once cached, since there is no server round-trip involved.

Mochify's video tool takes the same approach: conversion happens in your browser. The video never leaves your device. See also Privacy and Image Optimization for a broader look at the data-handling landscape for online media tools.