Best format for screen recording: container vs codec, decided

The file extension names the box, not what is inside it#

Rename a .mov to .mp4 and, more often than not, it still plays. That is the tell that "MP4 vs MOV vs WebM" is the wrong question to open with, because those three names describe the container, the outer wrapper that holds the video and audio streams, and the container is not the thing that decides how large the file is or where it will play. That job belongs to the codec, the algorithm that actually compressed the pixels, and it sits one layer down where the extension cannot show it. An .mp4 can hold H.264, HEVC, or AV1; a .webm holds VP9 or AV1; a .mov holds H.264 or ProRes. Two files with the same extension can be a tenth of each other's size and open on completely different sets of devices, because the extension was never the format that mattered.

So this page splits the one decision your recorder hides behind a "format" dropdown into the two it really is: which container to wrap the file in, and which codec to compress it with. Get both right and a screen recording plays everywhere at the smallest honest size. This is the format layer of the wider capture-settings checklist; resolution and frame rate, which set how many pixels you are compressing in the first place, are decided one step before this.

Two decisions hide behind one dropdown#

The container picks compatibility and what codecs it is allowed to carry. MDN calls MP4 "the industry standard for video content, widely supported across devices and browsers"¹, which is why it is the safe wrapper for anything you hand to another person. WebM is "an open, royalty-free container" designed for the web¹, and QuickTime's .mov is, in MDN's words, effectively "primarily available on Apple devices" and "no longer widely used on the internet": useful as an editing wrapper on a Mac, wrong as a thing you send.

The codec picks size and, again, compatibility, plus a third axis the container does not have: licensing. Here is the pairing, because the cell you land in is the combination, not either axis alone.

Read it as two questions. The container decides whether a browser or a colleague's phone will open the file at all; the codec decides how many bytes it took to get there. The rest of this page is the codec column, because that is where the up-to-50-percent decisions live.

Three codecs, and the bytes each one saves#

H.264, also called AVC, is the one that plays everywhere. MDN lists it as supported by "all versions of Chrome, Edge, Firefox, Opera, and Safari"², and hardware to decode it sits in nearly every device shipped in the last decade. It is patented, but the Via LA pool "does not require license fees for streaming internet video ... as long as the video is free for end users"², so a free-to-watch product demo owes nothing. It is also the least efficient of the three, which is the price of being universal.

VP9 is Google's open codec, and per Google it "can reduce video bit rates by as much as 50% compared with other known codecs"³ at the same quality; MDN rates its quality "comparable to that of HEVC at similar bit rates"². It plays in every current browser and is the native codec for a WebM file. AV1, from the Alliance for Open Media, goes further: MDN credits it with "as much as 50% higher" compression "rates than AVC," and unlike H.264 it is "fully royalty-free"². Both buy a much smaller file. Both charge for it in a currency the next section spends. HEVC/H.265, the fourth row, matches that efficiency but is licensed by developer fees and barely plays on the open web², so it rarely earns a place in a screen-recording pipeline.

The compatibility tax: when a smaller file costs more than it saves#

A codec that halves the file is a win only if the viewer's device can decode it, and this is where the newer codecs bill you. AV1's reach is broad but not total: caniuse puts global support near 93% (roughly 79% full plus 14% partial) as of 2026, with Safari on macOS and iOS only partially supporting it since version 17.0⁴. VP9 is safer but still misses older Safari. H.264, again, misses nothing.

The second half of the tax is encode time. AV1 in particular is slow to compress: footage that H.264 encodes in real time on hardware can take many times longer in a good AV1 software encoder, so the bytes you save on delivery you pay back in CPU on the way out. And because no single modern codec plays truly everywhere, using one for a web embed means shipping a fallback: list a WebM or AV1 source and an MP4/H.264 source, so that when a browser cannot play the first, in MDN's phrasing, "it moves on to the next option"¹. That two-file arrangement is worth it for a self-hosted embed watched at scale and pure overhead for a clip you are emailing one person. The tax is only worth paying when the same file is served many times.

Capture format and delivery format are not the same file#

The costly mistake is treating the format you record in as the format you ship. They are two jobs. At capture, the recorder wants to write frames fast without pinning the CPU, so its default is a low-compression or near-lossless codec that produces a big file cheaply, which is correct, because compressing hard in real time steals cycles from the thing you are recording. At delivery you want the opposite: the smallest file that still plays, compressed once, slowly, offline. Compress twice, a heavy codec at capture and again at export, and the second pass quantizes the artifacts the first one introduced, so the text you were careful to keep crisp softens for nothing.

That is what a mastering codec is for. Apple's ProRes, wrapped in a .mov, is Apple's professional post-production codec⁶: it stores each frame nearly whole, so quality survives being cut, color-graded, and re-exported without generation loss, at the cost of a file many times larger than the H.264 you finally deliver. ffmpeg ships a ProRes encoder (prores_ks) alongside its H.264, VP9, and AV1 encoders, and it exposes AV1's own constant-quality knob on a 0-to-63 scale where higher means smaller and worse⁵, so one tool takes the master to the deliverable. The rule the pillar states for bitrate holds for format too: record at near-lossless quality and compress once on export, never at both ends.

Pick the format from where the video lands#

The pattern under the table is one line: default to MP4/H.264 and leave it only for a named reason. Sending the clip to a person, a channel, or a pull request keeps MP4/H.264, which plays with zero fallback and no thought. A self-hosted web embed where bytes are your bill earns WebM/VP9 with an MP4 fallback, banking as much as half the bytes while the browser chooses. An App Store upload is decided for you: Apple fixes container and codec, and it is H.264. A file you will keep editing wants a ProRes master in a .mov, exported to a delivery codec when the edit is done. And a clip bound for YouTube or a streaming host should go up as clean H.264, because they will transcode it to their own ladder regardless, so a slow AV1 upload buys nothing.

Making that choice once and never fumbling it again is easier when the container and codec are written down rather than picked from an export menu under deadline. In our own engine, aidemo, both live in the storyboard, so every re-render of a demo comes out as the same H.264 MP4 because the whole capture is deterministic, with no dropdown to get wrong. The honest limits are the usual ones: aidemo captures a browser and not a native desktop app, a coding agent writes the storyboard in code instead of dragging clips through a GUI editor, and for one throwaway clip a point-and-click recorder beats setting up a spec.

Sources#

1. MDN — Media container formats (MP4, WebM, QuickTime; which codecs each holds)
2. MDN — Web video codec guide (H.264, VP9, AV1, HEVC efficiency and licensing)
3. Google — VP9 (bit-rate reduction up to 50%)
4. caniuse — AV1 video format (browser support, 2026)
5. FFmpeg — Codecs documentation (libaom-av1 crf 0-63, prores_ks encoder)
6. Apple — About Apple ProRes

FAQ#

What is the best format for screen recording?#

For almost everything you send or embed, an MP4 file with the H.264 codec, because it plays in every browser and on nearly every device with no fallback and owes no license fee for free-to-watch video. Leave that default only for a specific reason: WebM with VP9 (or AV1) for a self-hosted web embed where a file up to half the size is worth shipping an MP4 fallback beside it, and a ProRes .mov when the file is a master you will keep editing rather than a thing you deliver.

What is the difference between a video container and a codec?#

The codec is the algorithm that compressed the pixels (H.264, VP9, AV1); the container is the wrapper that holds the compressed video and audio together (.mp4, .webm, .mov). The extension names the container, not the codec, which is why two .mp4 files can differ tenfold in size and play on different devices depending on which codec is inside. Pick the container for compatibility and the codec for file size, then confirm the codec you chose is one your container is allowed to carry.

Is MP4 or MOV better for a screen recording you send to someone?#

MP4. MDN calls MP4 the industry-standard video container, widely supported across devices and browsers, while it describes QuickTime's .mov as primarily an Apple-device format that is no longer widely used online and deprecated for the web. MOV still earns its place as an editing master, since ProRes lives in a .mov, but for a file another person has to open, export to MP4/H.264 so it plays without them installing anything.