All guides
Media 9 min readUpdated October 2026

Video Formats and Codecs Explained: Choosing the Right One

A guide to video for the web: separating container from codec, the common codecs, resolution and framerate, choosing a bitrate, trimming and converting, and verifying the result while keeping the source.

Step 1 — Separate container from codec

A video file is two things: a container and a codec, and confusing them is the most common source of misunderstanding. The container (the format, like MP4, WebM, or MOV) is the package that holds the video stream, the audio stream, subtitles, and metadata together. The codec (like H.264, H.265, or VP9) is the algorithm that compresses and decompresses the actual video and audio data inside the container.

The file extension usually names the container: a .mp4 file uses the MP4 container, a .webm file uses WebM. But the codec inside is a separate choice — an MP4 container can hold video encoded with H.264, H.265, or AV1, and the choice of codec determines quality, size, and compatibility far more than the container does. Two .mp4 files with different codecs can behave very differently.

This separation matters because compatibility is about both. A browser that supports the MP4 container may not support every codec that can live inside it, which is why a video that plays in one player fails in another despite having the same format. The practical discipline: when a video does not play, the first question is what codec it contains, not what extension it has.

Step 2 — Know the common codecs

H.264 (AVC) is the most universally compatible video codec. Every modern browser, phone, and player supports it, which is why it remains the default for web video despite being older. Its compression is good but not the best — newer codecs achieve the same quality at smaller sizes. For maximum compatibility, H.264 in an MP4 container is the safe choice.

H.265 (HEVC) is the successor to H.264, offering roughly 50 percent better compression — the same quality at half the bitrate, or better quality at the same size. Its weakness is licensing and support: it is not supported in all browsers (notably older versions and some open-source builds), which limits its use for web distribution despite its efficiency.

AV1 and VP9 are the modern open codecs. VP9, used in WebM containers, is supported by all major browsers except older Safari and achieves better compression than H.264. AV1 is the newest, offering the best compression of all, but encoding is slow and hardware support is still catching up. For web video where modern browsers are the target, VP9 or AV1 in a WebM container offers the best size-to-quality ratio; for universal compatibility, H.264 in MP4 remains the fallback.

Step 3 — Understand resolution and framerate

Resolution is the number of pixels in each frame, described as width by height (1920x1080, 1280x720). Higher resolution means more detail but dramatically larger files, because the pixel count scales with the product of the dimensions — a 4K frame (3840x2160) has four times the pixels of a 1080p frame, and roughly four times the data to encode.

The right resolution depends on where the video is viewed. A 1080p video is the standard for most web content — it looks sharp on phones and laptops without the size penalty of 4K. 720p is acceptable for content viewed on small screens or where bandwidth is constrained. 4K is justified only when the viewer has a 4K display and the bandwidth to stream it; serving 4K to a phone wastes data the viewer will never see.

Framerate, measured in frames per second (fps), is how many images per second the video contains. 24 fps is the cinematic standard; 30 fps is standard for web video; 60 fps is used for smooth motion in gaming and sports content. Higher framerates smooth motion but increase file size, because more frames must be encoded per second. For most web content, 30 fps is the right balance of smoothness and size.

Step 4 — Choose a bitrate

Bitrate is the primary determinant of video quality and size, measured in megabits per second (Mbps). Higher bitrates preserve more detail but produce larger files. The relationship is roughly linear with size, but quality improves only up to a point — beyond the transparency threshold, additional bitrate adds size with no visible improvement.

Useful bitrates depend on resolution and content complexity. For 1080p web video, 3 to 5 Mbps produces good quality for most content; 8 Mbps is high quality; beyond that, returns diminish. Action-heavy content with lots of motion needs higher bitrates than talking-head content, because motion creates more information to encode. Static scenes compress extremely well; chaotic scenes do not.

Variable bitrate (VBR) allocates more bits to complex scenes and fewer to simple ones, achieving better quality at a smaller average size than constant bitrate (CBR). Two-pass encoding analyzes the entire video before encoding to allocate bits optimally, producing the best quality for a target size at the cost of longer encoding time. For web distribution, VBR (ideally two-pass) is the right choice; for live streaming where encoding must happen in real time, CBR predictability is necessary.

Step 5 — Trim and convert before distributing

Before distributing a video, trim it to the relevant section. Removing unwanted footage at the start and end, cutting dead air, and extracting the meaningful excerpt reduces duration, which reduces file size directly. The Video Tools include a trimmer that performs these cuts, ideally on the source before any re-encoding, so no quality is lost in the trim itself.

Converting between formats and codecs is the step where quality and size decisions are made. Converting from a high-bitrate source to a web-distribution format involves choosing the codec (H.264 for compatibility, VP9 or AV1 for size), the resolution (1080p for most web content), and the bitrate (VBR at a target appropriate to the content). Each of these is a trade-off, and the right combination depends on the audience devices and bandwidth.

Merging multiple clips into a single file before encoding avoids the quality loss of encoding clips separately and concatenating. The workflow — trim and merge on the source, then encode once to the final format — preserves maximum quality. The Video Tools perform these operations locally in the browser, so the source video does not leave your device during trimming and merging, though the final encoding step quality decisions are one-way and worth verifying.

A worked example: encoding a 5-minute web video

Consider a 5-minute tutorial video, originally recorded at 1080p, 30 fps, that weighs 1.2 GB as raw source footage. The goal is web distribution that loads quickly on both phones and laptops. The decisions are codec, resolution, and bitrate — in that order, because each constrains the next.

Codec first: H.264 in an MP4 container for universal compatibility, since the audience includes older devices. Resolution: 1080p is appropriate for a tutorial viewed on laptops; if the primary audience is mobile, 720p halves the pixel count and the data. Bitrate: for 1080p talking-head content at 30 fps, 3 to 4 Mbps with variable bitrate produces clean results — the content has limited motion, so it does not need the 8+ Mbps that action footage demands.

The math: 5 minutes times 60 seconds times 4 megabits per second, divided by 8, gives roughly 150 MB for the video stream, plus perhaps 5 MB for audio at 128 kbps — a final file of about 155 MB, under 13% of the source. Had the bitrate been set to 8 Mbps by default, the file would be 300 MB with no visible improvement for this content. The framework: choose codec by compatibility needs, resolution by viewing device, and bitrate by content complexity — then verify by watching on the devices your audience uses, because the only honest test of a bitrate is whether the result looks right where it is actually watched.

Step 6 — Verify and keep the source

After encoding, watch the result on the devices your audience will use. Compression artifacts — blockiness in dark scenes, banding in smooth gradients, blurring during fast motion — are most visible on large screens and in content with the detail or motion that stresses the encoder. A quick check on a phone and a laptop catches the problems that matter for web distribution.

Keep the source. Video encoding to a lossy format is a one-way operation — the discarded visual data cannot be recovered from the compressed file. If you later need a higher quality version, a different codec, or a different resolution, you must re-encode from the source, not from the lossy file, because re-encoding a lossy file compounds artifacts with each generation. This is the same discipline as in audio and images: the source is the master, the encoded file is the distribution copy.

Finally, match the format to the audience. H.264 in MP4 for universal compatibility, VP9 or AV1 in WebM for the best size-to-quality on modern browsers, and a resolution and bitrate appropriate to where the video is viewed. The right choice is the smallest file that looks good to your viewers on their devices — and verifying that by watching, not by trusting a bitrate number, is what makes the choice reliable.

Try the related tools