
MOQ vs WebRTC has become one of the most talked-about topics in the live streaming space over the past few months.I’ll share a more detailed blog about this new live streaming technology soon, but first, I’d like to address the latest buzz happening around it. In this blog, I will share the latest industry discussions comparing WebRTC and MOQ, along with my perspective as the co-founder and CEO of Red5, and you will learn why these two protocols aren’t competitors and can coexist in 2025.
Cloudflare published a blog post about MOQ in August, describing it as the ultimate solution to all of today’s real-time media transmission challenges. Most of its focus was on comparing MOQ to WebRTC and pointing out everything they could think of that’s bad about WebRTC.
Philipp Hancke from WebRTCHacks responded with an article titled “Is Everyone Switching to MoQ from WebRTC?.” In his post, Philipp explains that Cloudflare’s piece misrepresents WebRTC by suggesting it is purely a peer-to-peer protocol, overlooking the fact that most real-world deployments (like Red5) rely on server-based SFU architectures. He highlights that WebRTC remains stable, widely used, and proven at scale, while MOQ is still experimental, with limited adoption and inconsistent usage data in Chrome metrics.
Where I think Phillip took a wrong turn was spending a huge amount of time comparing usage numbers of MOQ and WebRTC. This part seemed really misleading to me. Of course MOQ is a very new and emerging protocol, and WebRTC has been around for over a decade and is well established. So, of course the usage of MOQ is tiny with lots of fits and starts, and yes, WebRTC is much larger and steady.
I think the goals of MOQ are exciting, and I’m happy to see it succeed.
Sean DuBois also chimed in and shared his perspective on LinkedIn, sparking some interesting conversations.
I agree with Sean that CloudFlare needlessly bashed WebRTC, and much of what they described as its shortcomings were misleading at best, and in some cases flat out wrong. That said, trying to position MOQ as not relevant, claiming that no one is switching to MOQ based on usage statistics we have today is equally misleading.


In my opinion, MOQ and WebRTC will co-exist for quite some time. Will you typically use the two technologies together at the same time? More than likely not. Most use cases in live real-time video streaming I believe will be run on MOQ in the future. But we’re far from that in 2025\.
If you’ve not already guessed, we at Red5 are already adding the MOQ protocol to both Red5 Cloud and Red5 Pro, with a release set by the end of 2025\. We started with RTMP in the Flash days and now support RTSP, SRT, HLS, Zixi, and more. We recommend the protocols that best fit our customers’ use cases and requirements. MOQ is the next step in that evolution.
In short, WebRTC remains the best choice for ultra-low latency browser-based streaming, while MOQ introduces a simpler, scalable approach built on QUIC for future real-time and hybrid use cases. Together, they represent the next stage in live streaming technology, and Red5 will support both by the end of 2025.
MOQ might be today’s “flavor-of-the-month”, but things evolve, and down the road, there will be a new flavor. Then the argument between MOQ and the newer protocol will be similar to what’s being argued here between MOQ and WebRTC.
Interesting comparison — WebRTC and MOQ are often framed as alternatives, but in practice they serve different bottlenecks. WebRTC’s strength is in real-time bidirectional media + NAT traversal and large-mesh optimizations (with SFU/MCU patterns), whereas MOQ’s value tends to be in efficient multicast distribution with minimal state for large audiences.
For many dev use cases, the choice isn’t just latency vs throughput — it’s predictability under load, peer count, transport cost, and failure handling.
Curious — in your view, which operational signal most clearly distinguishes when WebRTC is the right fit vs when MOQ shines (e.g., peer count thresholds, server cost per stream, or end-to-end latency under load)? That usually tells engineers where to draw the line.