Your cameras record in H.265 because it delivers similar quality at roughly half the bitrate, which halves what you pay to keep thirty days of footage.

Most browsers cannot play it. The two that can need the right hardware underneath, and they negotiate it per call.

Everything expensive about putting existing video into a browser follows from that gap — and the gap exists for reasons that have nothing to do with engineering.

WebRTC H265 support, browser by browser

The current state, which is narrower than the marketing around H.265 suggests:

Browser	H.265 over WebRTC	Detail
Chrome	Yes — since 136	Shipped stable April 2025. Included in SDP offer/answer only where hardware encode and decode are available.
Safari	Yes — since 18.0	Enabled by default, same hardware dependency.
Firefox	No	Not supported, and no stated plan to implement.
Edge	No	Listed in the 136 release notes, then removed. Never enabled in the shipped product.

Sources for each: Chrome Platform Status for the Chrome shipping record, Microsoft's own response on Edge, and this survey of WebRTC HEVC support for the Safari and Firefox positions.

This moves. Check it the week you ship anything that depends on it rather than trusting a table in a blog post, including this one.

Why WebRTC H265 support stalled — and it was not engineering

H.265 is a good codec. The compression gain over H.264 is real and the encoders are mature. None of that is why browsers held back.

H.264 was licensed through essentially one pool, which meant an implementer could look up the cost of shipping it and decide. H.265 fragmented: four separate licensing entities — MPEG LA, HEVC Advance, Velos Media and independent licensors — each with their own terms.

The consequence was not that H.265 was expensive. It was that nobody could work out in advance what it would cost. Implementers could not calculate total royalty exposure, so many avoided the codec entirely rather than sign up for an unbounded liability.

Browser vendors were in exactly that position, at the worst possible scale — a royalty per installed browser, across billions of installations, with no ceiling anyone could quote. Google and Mozilla declined on those grounds, and YouTube moved to VP9 and later AV1 specifically to route around HEVC royalties.

So the support matrix above is a map of licensing decisions. Which explains the one row that otherwise makes no sense.

The Edge anomaly, and what it proves

Edge is built on Chromium. It ships the same engine as Chrome, which means the H.265 code is present in the codebase it compiles.

Edge 136 even listed WebRTC H.265 support in its release notes in May 2025. Seven months later Microsoft removed the reference and confirmed the capability had never been enabled in the shipped product — the documentation had simply been corrected to match reality. MediaRecorder HEVC works in Edge for recording; WebRTC H.265 transmission does not, even on hardware with HEVC encode. There is no published roadmap.

Same engine, same hardware, opposite answer. That is not a technical constraint — it is two companies reaching different conclusions about the same licensing question, and it is the clearest evidence you will find that codec availability is a business decision wearing technical clothing.

What "supported" actually means here

Two qualifications turn the green cells in that table into something much less reliable.

First, hardware. Both Chrome and Safari include H.265 in their session description only when the device has hardware encode and decode available. A user on older hardware, a virtual machine, or a device whose drivers do not expose HEVC will silently not offer it. "Chrome supports H.265" and "your users can use H.265" are different statements, and only the second one matters.

Second, negotiation. Codecs are negotiated per call, as an intersection of what both sides offer. Two Chrome users on capable hardware get H.265. One of them on a Firefox laptop, and the call falls back to H.264 for everyone. You cannot rely on a codec you do not control on both ends.

The practical read: H.265 over WebRTC is an optimisation that sometimes applies, never a foundation you can build on. Any design that requires it will fail for a predictable share of users, on their hardware, which you cannot fix.

Where this actually bites: the archive disagrees with the browser

For a greenfield conferencing product this is a minor annoyance — use H.264 and move on.

It becomes expensive when you already have H.265 video. Modern IP cameras ship H.265 by default precisely because storage is the dominant cost in surveillance, and halving the bitrate halves the retention bill. So the recorded archive is H.265, the cameras are H.265, and the browser the operator wants to watch from mostly is not.

That gap has to close somewhere, and the options are all worse than they look. RTSP cameras still cannot talk to browsers directly, so something already sits in the path; the codec mismatch decides how expensive that something is. Where you tap the stream — camera, NVR, or a parallel path — determines whether you are transcoding one feed or all of them.

The transcode bill

Converting H.265 to H.264 on the live path means a full decode and a full re-encode, per stream, in real time.

Compare that to the alternative. An SFU forwards without decoding — it rewrites packet headers and sends the bytes on, which is why forwarding capacity is measured in hundreds of streams per CPU core. Transcoding is measured in streams per core. The gap between those two units is the whole cost of the mismatch.

Three things follow, in increasing order of how much they hurt:

Compute. A transcoding tier is an order of magnitude more hardware than a forwarding tier for the same stream count, and it scales with publishers rather than viewers — so a camera estate pays for every camera, whether anyone is watching or not.
Latency. Decode and re-encode add milliseconds to a path where the whole argument for WebRTC was that it was fast. A transcoder is a permanent tax on the number you were selling.
Quality. Re-encoding lossy video is generationally lossy. You are decoding an approximation and approximating it again, and no setting makes that free.

And it stacks with the constraint that is already there: forwarding is cheap and decoding is not applies on the client too, which is why an operator's workstation caps out long before the network does. Transcoding on the server does not remove that ceiling — it just adds a second one upstream.

So what should you actually pick?

Split the decision by leg, because the right answer genuinely differs.

Leg	Codec	Why
Camera to recorder, and storage	H.265	Halves the bitrate for similar quality. Storage is the dominant cost and both ends are hardware you control.
Live path to a browser	H.264	Universal. No negotiation risk, no hardware dependency, no transcoder.
Live path, both ends known capable	H.265 opportunistically	Fine as an upgrade that degrades to H.264. Never as a requirement.
Forward-looking web delivery	Watch AV1	Designed to avoid the licensing problem, though not provably free of it.

The honest position is that H.265 is not the villain here. For storage and for the camera leg it is straightforwardly the right choice, and picking it there was correct. The mistake is assuming a codec that won the camera market also won the browser — those markets made their decisions on completely different criteria, and only one of them was compression.

On AV1: it was designed specifically to deliver the compression gains without the licensing uncertainty, and it is where royalty-free web video is heading. It is worth noting honestly that even that is not settled — Sisvel has launched an AV1 patent pool asserting essential patents, which AOMedia disputes. "Royalty-free" is a design intent rather than a proven legal fact, for any modern codec.

Build, Buy, or Deploy

Three routes, with the honest boundary on each.

Build on open source

mediasoup, Janus, Pion and LiveKit all forward H.264 without decoding it, which is the cheap path. If you need H.265 in and H.264 out you are adding a transcoding tier yourself — typically FFmpeg or GStreamer with hardware acceleration — and that is a real component with its own scaling behaviour, failure modes and licensing questions of its own. Budget it as infrastructure, not as a configuration flag.

Buy a cloud video API

Per-minute providers standardise on H.264 and handle negotiation for you, which removes this problem for conferencing use cases entirely. The limit shows up when you have existing H.265 sources: most will not ingest them, so the transcode still has to happen somewhere on your side before their pipeline begins.

Deploy a commercial platform

The middle path runs a commercial platform on infrastructure you choose. Samvyo is one such option: based on SFU architecture, shipping embeddable SDKs, with the media path, TURN and recording kept on infrastructure you control. Controlling the media path matters specifically here, because where the codec conversion happens — and whether it happens once at the edge or repeatedly per viewer — is the difference between a manageable cost and a runaway one. It is resilient by design rather than something you assemble.

Where it does not fit: for pure conferencing with no legacy sources, H.264 end to end needs none of this. And if your entire estate is H.265 and every viewer is on managed hardware you control, you may be able to run H.265 straight through and skip the conversion entirely.

The Bottom Line

H.265 halves your storage and cannot be relied on in a browser. Chrome 136 and Safari 18 support it with hardware encode and decode present; Firefox does not, and Edge ships the same Chromium engine as Chrome and still has not enabled it — which tells you this is a licensing outcome, not a technical one. Four patent pools against H.264's one made the cost unknowable, and unknowable is worse than expensive.

Keep H.265 where it earns its place: the camera leg and the archive. Keep H.264 as the floor on anything that reaches a browser. Treat H.265 over WebRTC as an opportunistic upgrade that must degrade cleanly — and if an architecture requires a transcode on the live path, price that transcoder honestly, because it costs compute, latency and quality all at once.

What's Next

Codec negotiation is one stage of a longer chain — the full chain between two video tabs walks all eight and what fails at each. If the mismatch you are facing is a camera estate rather than a conferencing product, RTSP cameras still cannot talk to browsers directly covers the transport half of the same problem.

Frequently Asked Questions

Does WebRTC support H.265?

Partially. Chrome has supported it since version 136 and Safari since 18.0, both only when the device has hardware encode and decode available. Firefox does not support it and has no stated plan to. Edge does not support it either, despite running the same Chromium engine as Chrome. Because codecs are negotiated as an intersection, a single participant without H.265 drops the whole call back to H.264.

Why don't all browsers support H.265?

Patent licensing, not engineering. H.264 was licensed through essentially one pool, so implementers could calculate the cost of shipping it. H.265 fragmented across four separate licensing entities, which made total royalty exposure impossible to determine in advance. At browser scale that is an unbounded liability, so several vendors declined and YouTube moved to VP9 and AV1 to avoid it.

Should I use H.264 or H.265 for WebRTC?

H.264 for anything reaching a browser. It is universal, needs no hardware check and no negotiation risk. Use H.265 opportunistically only where both ends are known to support it, and design so the call degrades cleanly to H.264 when they do not. Never make H.265 a requirement on the live path.

Why does Edge not support H.265 in WebRTC if it uses Chromium?

Because the capability was never enabled, regardless of the engine. Edge 136 listed it in its release notes in May 2025; Microsoft removed the reference seven months later and confirmed it had not shipped. MediaRecorder HEVC works for recording, but WebRTC transmission does not, even on hardware with HEVC encode, and there is no published roadmap.

What does it cost to transcode H.265 to H.264 for live streaming?

Substantially more than forwarding. An SFU forwards without decoding, so its capacity is measured in hundreds of streams per CPU core; transcoding requires a full decode and re-encode per stream and is measured in streams per core. It also adds latency to the live path and loses quality, since re-encoding already-lossy video is generationally lossy.

My cameras record in H.265 — can operators watch them in a browser?

Only via conversion, unless every operator is on Chrome or Safari with capable hardware, which is not a safe assumption. Something already sits between an IP camera and a browser because RTSP cannot reach one directly; the codec mismatch determines how expensive that component is. Tapping the stream in the right place decides whether you transcode one feed or all of them.

Is AV1 the answer to the H.265 licensing problem?

It is the direction, with a caveat. AV1 was designed to deliver the compression gains without the licensing uncertainty, and it is where royalty-free web video is heading. But Sisvel has launched an AV1 patent pool asserting essential patents, which AOMedia disputes — so treat royalty-free as a design intent rather than a settled legal fact for any modern codec.

Subscribe to Samvyo blogs