H.264 (AVC) is the compatibility default. H.265 (HEVC) is the efficiency upgrade. H.265 was designed to reach the same perceptual quality at roughly half the bitrate, and it costs more CPU to encode and needs newer hardware to decode. Use H.264 when the receiver is unknown. Use H.265 when you control the endpoints and bandwidth or storage is the constraint.
Both are video codecs, not file formats. A codec decides how pixels are compressed. A container such as MP4 or MKV decides how the compressed result is packaged. The two questions are independent, and mixing them up is the most common error in this topic.
H.264 vs H.265 at a glance
| H.264 / AVC | H.265 / HEVC | |
|---|---|---|
| Published | 2003 (ITU-T H.264, ISO/IEC 14496-10) | 2013 (ITU-T H.265, ISO/IEC 23008-2) |
| Block structure | Macroblocks, fixed 16x16 | Coding Tree Units, 64x64 down to 8x8 |
| Design target | Baseline | About 50% bitrate reduction at equal perceptual quality |
| Encode cost | Lower | Substantially higher at comparable settings |
| Decode support | Effectively universal | Newer hardware, uneven in browsers |
| Browser playback | All major browsers | Safari 13+, Chrome 107+ (partial), Firefox 137+ |
| WebRTC | Mandatory to implement (RFC 7742) | Optional, Chrome and Safari only |
| Licensing | One main pool | Multiple pools, more complex |
| Best at | Reach, real-time, low encode budget | 4K and above, storage, bandwidth-constrained VOD |
| Symptom when wrong | Higher bitrate than necessary | Black frames or CPU-bound playback on old devices |
What is H.264?
H.264 is defined as a block-oriented, motion-compensated video compression standard published jointly in 2003 as ITU-T Recommendation H.264 and ISO/IEC 14496-10, also called MPEG-4 Part 10 or AVC (Advanced Video Coding).
H.264 works by splitting each frame into macroblocks of 16x16 pixels, predicting each block either from neighbouring blocks in the same frame (intra prediction) or from a matching region in a previously coded frame (inter prediction), then transforming and quantising only the prediction error.
Why H.264 is still the default
Two reasons, and neither is technical superiority. First, hardware decoders shipped in essentially every phone, laptop, TV, and set-top box built after roughly 2006, so playback is free in power terms almost everywhere. Second, RFC 7742 makes H.264 Constrained Baseline mandatory to implement for WebRTC browsers, which means any browser-based call can fall back to it. Reach beats efficiency when you do not control the receiving device.
H.264 profiles matter more than most articles admit
"H.264" is not one thing. Constrained Baseline drops B-frames and CABAC entropy coding, which lowers both quality-per-bit and decoder complexity. High Profile adds both back and is what streaming services actually ship. A Constrained Baseline stream and a High Profile stream at the same bitrate are visibly different, so any H.264-versus-H.265 comparison that does not name the profile is under-specified.
What is H.265?
H.265 is defined as the successor video compression standard published in 2013 as ITU-T Recommendation H.265 and ISO/IEC 23008-2, known as HEVC (High Efficiency Video Coding).
H.265 works by replacing fixed macroblocks with a quadtree of Coding Tree Units that can span 64x64 pixels and subdivide down to 8x8, so flat regions are described with far fewer blocks while detailed regions keep fine granularity. It adds 33 intra-prediction directions against H.264's 9, and better motion vector prediction.
How much bandwidth does H.265 actually save?
The stated design goal for HEVC was roughly 50% bitrate reduction at equivalent subjective quality against H.264. Treat that as the standard's target, not as a number you will measure.
What you actually get depends on resolution, content, encoder, and preset:
- Gains are largest at high resolution. The bigger CTUs pay off most on 4K and 8K, where large uniform areas dominate.
- Gains shrink at low resolution and low bitrate, where H.264's smaller blocks are already a reasonable fit.
- Gains shrink on high-motion content, where prediction works less well for both codecs.
- Gains shrink at fast presets, because the tools that produce HEVC's advantage are the expensive ones, and real-time presets skip them.
Practical planning figures for 30 fps, using H.264 High Profile as the baseline:
| Resolution | H.264 typical bitrate | H.265 typical bitrate |
|---|---|---|
| 360p | 0.6 to 1.0 Mbps | 0.4 to 0.7 Mbps |
| 720p | 1.5 to 2.5 Mbps | 1.0 to 1.7 Mbps |
| 1080p | 3.0 to 4.5 Mbps | 2.0 to 3.0 Mbps |
| 4K | 15 to 25 Mbps | 8 to 15 Mbps |
These are planning ranges for encoder configuration, not benchmark results. Measure your own content before committing capacity.
Encoding cost is the hidden line item
H.265's efficiency is bought with search. The quadtree partitioning, larger prediction unit set, and extra intra directions all mean more candidate evaluations per block. On CPU encoding at comparable quality targets, HEVC encodes meaningfully slower than H.264 at equivalent presets, and the ratio widens as you move toward slower, higher-quality presets.
For an offline transcode this is a cost question. For a live encode it is a latency question, because encoder time lands directly in the glass-to-glass budget. This is the single most important reason real-time systems still default to H.264.
H.264 vs H.265 compatibility
Browser support
| Browser | H.264 | H.265 / HEVC |
|---|---|---|
| Chrome | Yes | Partial from 107 |
| Edge | Yes | Partial |
| Firefox | Yes | Partial from 137 |
| Safari (macOS) | Yes | Yes from 13 |
| Safari (iOS) | Yes | Yes from 11 |
| Samsung Internet | Yes | Yes from 21 |
"Partial" is doing real work in that table. Chrome and Firefox HEVC support is generally tied to platform hardware decoders being present, so it can be available on one machine and absent on another running the same browser version. Never treat HEVC playback as a static capability.
WebRTC support
This is where the two codecs diverge most sharply for real-time developers.
H.264 Constrained Baseline is mandatory to implement under RFC 7742, alongside VP8. Section 5 states that WebRTC browsers must implement both, which is why either can always be negotiated regardless of what else a browser supports.
H.265 has no such guarantee. Chrome shipped it in version 136 across desktop, Android, and WebView, and it is gated on hardware: Chrome does not ship a software HEVC encoder, so availability depends on the device and operating system rather than on the browser version alone. Safari has carried HEVC over WebRTC for longer, but Safari 18.0 was the release that added the standard RFC 7789 RTP payload format, replacing the generic packetization used before it. Support and interoperability are separate questions here.The correct pattern is to query at runtime rather than to branch on a user-agent string:
The consequence is that a static compatibility table cannot answer this. Two machines running the same Chrome build can differ, because one has a hardware HEVC encoder and the other does not. Query at runtime instead of branching on a user-agent string:
const send = RTCRtpSender.getCapabilities("video").codecs;
const recv = RTCRtpReceiver.getCapabilities("video").codecs;
const canSendHevc = send.some((c) => c.mimeType === "video/H265");
const canRecvHevc = recv.some((c) => c.mimeType === "video/H265");
console.log({ canSendHevc, canRecvHevc });
console.log("Sender codecs:", send.map((c) => c.mimeType));
Check both directions. Send and receive capabilities are reported separately and are not always the same, since hardware decode is far more common than hardware encode.
Licensing
H.264 licensing consolidated into a single main patent pool with well-understood terms. H.265 fragmented across several pools, which raised both cost and, more damagingly, uncertainty. That uncertainty is the main reason Google and Mozilla deprioritised HEVC and why AV1 exists as a royalty-free alternative.
Licensing is a legal question, not an engineering one. If you are distributing an encoder or decoder at scale, get advice rather than a blog's summary.
When to use H.264
- Browser-based real-time calls, where receiver capability is unknown.
- Any WebRTC path that must interoperate broadly, since it is mandatory to implement.
- Live encoding on a constrained CPU budget, where encoder time is latency.
- Content at 1080p and below, where HEVC's advantage is smallest.
- Maximum device reach, including older Android and legacy set-top boxes.
Not for: 4K and 8K libraries where storage or egress dominates cost.
When to use H.265
- 4K and 8K VOD, where the bitrate saving is largest and encoding is offline.
- Storage-bound archives, including long-retention surveillance.
- Apple-ecosystem apps, where hardware encode and decode are dependable.
- Bandwidth-constrained delivery to known, modern endpoints.
Not for: open-web playback to unknown browsers, or any real-time path where the encoder must keep up with the capture frame rate on modest hardware.
Where VP9 and AV1 fit
Neither is a footnote. VP9 is royalty-free, ships in Chrome, Firefox, and Edge, and sits close to HEVC in efficiency. AV1 is royalty-free, targets roughly 30% over HEVC as a design goal, is expensive to encode without hardware assistance, and now has hardware decode in recent GPUs and mobile SoCs.
For web delivery, VP9 and AV1 usually beat HEVC on licensing and browser reach. For Apple-native and broadcast pipelines, HEVC usually wins on hardware maturity. The codec question is rarely "which is best" and almost always "which is decodable on the devices I have to serve".
How to check which codec a file or stream is using
Guessing is unnecessary. For a file, ffprobe reports the codec directly:
ffprobe -v error -select_streams v:0 \
-show_entries stream=codec_name,profile,width,height,bit_rate \
-of default=noprint_wrappers=1 input.mp4
Typical output:
codec_name=h264
profile=High
width=1920
height=1080
bit_rate=4200000
Note that profile=High line. As covered above, H.264 High Profile and H.264 Constrained Baseline behave differently enough that a comparison without the profile is incomplete.
For a live WebRTC session, read the codec actually negotiated rather than the one you requested:
const stats = await peerConnection.getStats();
stats.forEach((stat) => {
if (stat.type === "outbound-rtp" && stat.kind === "video") {
const codec = stats.get(stat.codecId);
console.log("Sending:", codec?.mimeType, "at", stat.targetBitrate, "bps");
}
});
Negotiation can fall back without warning if the far end lacks your preferred codec, so the requested codec and the sent codec are not always the same.
H.264 vs H.265 for security cameras and surveillance
Surveillance is the one use case where H.265 usually wins outright, and the reason is retention rather than picture quality.
A camera recording continuously produces a fixed number of hours per day. Halving the bitrate roughly doubles retention on the same disk, or halves the storage bill for the same retention window. Encoding happens once, on a dedicated chip in the camera, so the encode cost that rules H.265 out of real-time browser calls is already paid in hardware.
Two cautions apply:
- The recorder and client must decode it. An older NVR or a browser-based viewing client may not, which turns a storage saving into an unviewable archive.
- Vendor "H.265+" and "Smart Codec" modes are not the standard. They typically add aggressive long-GOP and background-static encoding on top of HEVC. They save more space and can degrade evidential quality on motion, which matters if the footage is ever needed as evidence.
For streaming that same camera into a browser-based dashboard, the calculus flips back to H.264, because the viewing client is the constraint rather than the disk.
Definitions glossary
Codec: The algorithm that compresses and decompresses video (H.264, H.265, VP9, AV1). It decides how many bits a given picture costs, which makes it the layer where quality is set.
Container: The file format that wraps compressed streams (MP4, MKV, WebM). It never compresses anything and never affects quality.
Profile: A named subset of a codec's tools. H.264 Constrained Baseline omits B-frames and CABAC; High Profile includes both and produces better quality at the same bitrate.
CTU (Coding Tree Unit): H.265's variable block structure, spanning 64x64 pixels down to 8x8. It replaces H.264's fixed 16x16 macroblocks and is the main source of HEVC's efficiency.
Mandatory to implement: A codec that a conforming WebRTC implementation must support. RFC 7742 names VP8 and H.264 Constrained Baseline, which is why either can always be negotiated.
Key takeaways
- H.265 targets roughly half the bitrate of H.264 at equal perceptual quality. Treat that as the standard's design objective, not as a figure to plan capacity against without testing.
- Realised savings are largest at 4K and above, on low-motion content, at slow encoder presets. They shrink toward zero at 360p on high-motion footage at a real-time preset.
- H.264 remains the safe default for browser-based real-time video, because RFC 7742 makes it mandatory to implement and its faster encoder consumes less of the latency budget.
- H.265 wins clearly for 4K VOD, Apple-native pipelines, and surveillance retention, where encoding is offline or hardware-accelerated and storage dominates cost.
- Codec and container are separate decisions. H.264 and H.265 are codecs; MP4 and MKV are containers. Either codec travels in either container.
Build video that negotiates codecs properly
The H.264 vs H.265 decision matters less in real-time video than most teams expect, because you do not pick the codec, you offer it. Whatever the far end accepts is what actually gets sent. The useful question is what your SDK lets you offer, and what it does when negotiation falls back.
VideoSDK exposes that on track creation:
let customTrack = await VideoSDK.createCameraVideoTrack({
// The id of the camera to capture video from.
cameraId: "camera-id", // OPTIONAL
// Tunes the encoder for the kind of content you are sending.
optimizationMode: "motion", // "text" | "detail" | Default: "motion"
// Resolution (height x width) of the captured video.
encoderConfig: "h540p_w960p", // "h360p_w640p" | "h720p_w1280p" | Default: "h720p_w1280p"
// On mobile browsers, selects the front or rear camera.
facingMode: "environment", // "user" | Default: "environment"
// Whether to publish multiple resolution layers (simulcast).
multiStream: true, // false | Default: true
// Controls the quality and bandwidth trade-off.
bitrateMode: VideoSDK.Constants.BitrateMode.HIGH_QUALITY,
// BANDWIDTH_OPTIMIZED | BALANCED | Default: HIGH_QUALITY
// Maximum number of simulcast layers to publish.
maxLayer: 2, // 1 | 3 | Default: 2
// Video codec used for this track.
codec: VideoSDK.Constants.VideoCodec.H264,
// VP8 | VP9 | AV1 | Default: H264
});The JavaScript SDK accepts H264 (the default), VP8, VP9, and AV1. One constraint is worth knowing before you switch: VP9 and AV1 do not support multiStream, so choosing either disables simulcast and drops every receiver to a single shared layer. In a group call with mixed connections that usually costs more than the codec saves. The iOS SDK exposes a narrower set, so check per platform rather than assuming one list carries everywhere.
Where to go next
- Optimize video track guide covers every
encoderConfigvalue with its bitrate under eachbitrateMode, plus themaxLayerrules that decide how many simulcast layers you actually get. - Custom tracks API reference lists the full
createCameraVideoTrack()parameter set, with separate pages per platform. - Code samples if you would rather read a running quickstart than a parameter table.
- Discord is the fastest place to get a codec or simulcast question answered by someone who has shipped it.
Start building free with $20 in credit.
Which codec are you running in production, and did simulcast survive the decision? Drop a comment, the tradeoff is rarely obvious until you measure it.
Frequently asked questions
Is H.265 better than H.264?
H.265 is more efficient, not universally better. It targets the same perceptual quality at roughly half the bitrate, which makes it better for 4K storage and bandwidth-constrained delivery. H.264 is better wherever compatibility, encode speed, or low-latency real-time delivery matters more than bitrate.
Does H.265 use less bandwidth than H.264?
Yes, at equal perceptual quality. The design target is roughly 50% less, though realised savings depend on resolution, content, and encoder preset, and are largest at 4K and above. H.265 does not reduce latency, because bitrate and delay are separate properties.
Is H.265 good for live streaming?
It depends on where the encoding happens. For hardware-encoded broadcast contribution, H.265 works well. For browser-based real-time calls, H.264 remains safer because it is mandatory to implement in WebRTC and its encoder is faster, and encoder time counts against latency.
Can I convert H.264 to H.265 to improve quality?
No. Transcoding decodes the H.264 stream and re-encodes it, so the output inherits every artifact of the source and adds new ones. Transcoding to H.265 reduces file size at similar quality. It cannot recover detail that H.264 already discarded.
Do I need a special player for H.265?
Usually not on modern hardware, but support is uneven. Safari plays HEVC from version 13, Chrome from 107 and Firefox from 137, both generally requiring a platform hardware decoder. Old Android devices and older desktops may fail to decode it at all.
Which codec should I use for a video calling app?
H.264 or VP8, because RFC 7742 makes both mandatory to implement for WebRTC, so a call can always negotiate one of them. Treat H.265, VP9, and AV1 as opportunistic upgrades negotiated per-session via RTCRtpSender.getCapabilities().