What is a codec? (video vs. container)

A codec (short for coder-decoder) is the algorithm that compresses audio or video data down to a manageable size, and decompresses it again for playback or editing. Raw, uncompressed video is enormous, so a codec's whole job is squeezing that data down using math (predicting pixels from nearby frames, discarding detail the eye or ear won't miss) without losing so much quality that the result looks or sounds broken. H.264, H.265 (HEVC), VP9, and AV1 are video codecs. AAC, MP3, and Opus are audio codecs. A codec is not a file, not a file extension, and not something you can double-click. It's the compression method that lives inside a file.

Most "what is a codec" explainers blur this, and it's the actual source of confusion: MP4, MOV, and WebM are containers, not codecs. A container is a file wrapper, like a box, that holds encoded video, encoded audio, subtitles, and metadata together and defines how a player reads them back out. The codec is what's inside the box. An MP4 file almost always holds H.264 or H.265 video plus AAC audio, but MP4 doesn't require those specifically; it can also wrap VP9 or AV1. A WebM file typically wraps VP8 or VP9 video plus Opus or Vorbis audio. So "MP4 vs. H.264" isn't a real comparison, since one's a box and the other's what's packed inside it.

This is where codec vs. container stops being trivia and starts having consequences. pixeltools' video converter (src/lib/video-convert-engine.ts) tries a stream copy first on every conversion: repackaging the source video's already-encoded data straight into a new container, with zero re-encoding. Going from a .mov to .mp4 this way is instant and lossless, because both containers can hold the same H.264/AAC data unchanged, so nothing needs decoding and recompressing. It only works when the source codec is actually compatible with the target container. When it isn't, the tool falls back to a full re-encode using libx264 (H.264) at CRF 23, preset "veryfast", which takes real time because it has to decode the source, recompress it, and write new encoded data.

It's tempting to treat codec choice as a UI checkbox, but codec support is real, sometimes buggy software behavior. When pixeltools converts to WebM, the code deliberately skips the newer VP9 codec (libvpx-vp9) and encodes with the older VP8 (libvpx) instead. The reason is a documented, reproducible bug: libvpx-vp9 reliably throws a wasm "RuntimeError: memory access out of bounds" in this browser-based ffmpeg build, across every resolution and encoder setting tested. VP8 encodes the same source with no crash, at some cost to compression efficiency. A working file with an older codec beats a crash with a newer one. This is the kind of tradeoff that only shows up once you've actually tried to ship the encoder, not when you're just reading a spec sheet.

For video: H.264 has the widest hardware and software support of any codec in existence and is still the safe default. H.265 (HEVC) compresses roughly 25-50% smaller than H.264 at the same quality but has spottier browser and licensing support. VP9, Google's royalty-free codec, is common in web video and YouTube delivery. AV1 is the newest, compresses better than all of the above, but is slow to encode and still gaining hardware support. For audio: AAC is the standard companion to H.264/H.265 in MP4 files, MP3 remains the most universally playable, and Opus is the modern, efficient choice for web and voice audio, used inside WebM and many streaming pipelines.

For sharing a video that needs to play everywhere with no compatibility questions, use MP4 with H.264 video and AAC audio; almost every device, browser, and platform accepts it. For smaller files at the same visual quality and you control playback, H.265 or AV1 wins on compression but not on universal support. For web-native video meant for `