Choosing a Video Codec — H.264, H.265, ProRes, and DNxHR in Plain Terms

"Codec" and "container" (MP4, MOV, MKV) get conflated all the time. The container is just the wrapper — what actually decides file size, quality, and how painful editing will be is the codec inside it.

This post lines up the codecs you'll actually encounter and walks through which to pick at each stage: capture, edit, delivery, and archive.

Codecs Come in Two Flavors

Every codec is optimized for one of two opposite goals.

This split is the foundation of every codec choice. Delivery codecs work in your editor, but stuttering playback and slow renders are exactly what happens when you push them past their design intent.

The Main Codecs at a Glance

The Right Pick by Stage

Capture

You mostly take what the camera gives you. When the camera offers a choice, the rule of thumb is to pick whatever has the higher bit depth and richer chroma subsampling. See the companion post on 10-bit 4:2:2 for why.

Editing

This is where codec choice gets genuinely consequential. Three approaches:

1. Edit camera originals directly. Smallest disk footprint. Works fine on modern, capable machines — especially for H.264.
2. Transcode to an edit codec first. Convert to ProRes 422 or DNxHR HQ, then edit. Smoothest experience, but files balloon 3–5×.
3. Proxy editing. Keep the originals; edit with low-res stand-ins; conform back to originals at export. Hybrid — storage stays sane and performance stays great. Best for long-form or large-shoot projects.

If your editor starts hiccuping, that's the cue to move from approach 1 to 2 or 3.

Delivery

The delivery target dictates the codec. Without a spec, sensible defaults look like:

• Web / social / YouTube — H.264 (8–12 Mbps for 1080p, 35–50 Mbps for 4K)
• Broadcast / theatrical — ProRes 422 HQ or DNxHR HQ
• Client review — H.264 with size weighted over quality

The bitrate post goes deeper into the numbers.

Archive

Long-term storage runs on its own logic. The rule for anything you might want to use again is to keep the camera original.

• Don't transcode camera originals just to save space.
• Intermediate edit-codec files can be deleted at end of project.
• Keeping only the delivery file is the same as throwing away your options.

When disk reality bites, a mix of external drives plus cloud cold storage is the realistic compromise. Workflows like VideoTagger assume those originals stay around — and stay searchable — so they can be pulled back into the next project years later.

"Why Not Just Use H.265 for Everything?"

H.265 is roughly half the size of H.264 at equivalent quality. Sounds like a slam dunk, and often it is — but there are costs.

• Encoding is much slower than H.264 at comparable settings.
• Compatibility is uneven — older devices, some browsers, and some social platforms still stumble on H.265.
• Editing is heavier than H.264. Proxy workflows are nearly mandatory.

The honest answer: H.265 is the better choice when you control the audience's playback environment. Sharing internally or with editors? Go ahead. Distributing to an unknown public audience? H.264 is still the safer default.

VideoTagger Already Knows the Codec

VideoTagger analyzes each video as it enters the library and pulls the codec (H.264, HEVC, ProRes, and friends), bitrate, resolution, and frame rate straight from the file. The codec shows up in the file info panel, and you can filter the whole library by codec in a click — surfacing "every ProRes master" or "every H.265 delivery file" without ever manually tagging them. The more codecs your library mixes across capture, edit, delivery, and archive, the more this pays off.

Wrapping Up

Codec choice gets simpler when you map it stage by stage.

• Capture — highest bit depth and chroma the camera offers.
• Edit — if the editor strains, switch to ProRes / DNxHR or proxies.
• Delivery — follow the spec. No spec? H.264.
• Archive — keep camera originals. Don't archive just the delivery file.

H.264, H.265, ProRes, and DNxHR aren't competitors — they're different tools for different stages. A normal production uses several of them across one project, and that's the point.