For the 5% of readers who already know about Media over Quic, you almost certainly have your own opinion on this question, so feel free to skip the article and jump straight to the comments to explain why I’m wrong. For the other 95%, you’re probably like this right now: Not to worry my friends, we’ll get into Quic, how you send Media over it, and how that’s different from putting RTC on the Web. What is WebRTC? First, let’s do a quick recap on WebRTC. WebRTC is the API behind most video conferencing applications on the web. It’s also used for a bunch of other uses cases involving real-time video streaming. To illustrate this, consider a webinar application: Let’s build a Webinar app Let’s say you wanted to build a web application to host webinars. You’d need a host to be able to share their webcam video and audio, and potentially a screen-share in real-time. You’d also need participants to be able to consume those video streams from the host, and potentially share their own webcam video and audio to ask questions and/or for general interactivity. How WebRTC enables webinars The standard solution for building our webinar app would be to use WebRTC, which is a Web API designed primarily to facilitate video conferencing applications. In WebRTC applications, each participant uploads their audio and video as streams in real time, in most cases to a central server called a selective forwarding unit selective forwarding unit Each participant opens a connection to the server, grabs their own local webcam stream, negotiate with the server to coordinate on codec choice, bit rate etc.., and then start broadcasting to and subscribing streams from the server. In code it would look something like this: // SFU WebRTC: Single connection to server async function joinWebinar() { // 1. Get your webcam const localStream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true }); // 2. Create ONE peer connection (to the server, not to each participant) const peerConnection = new RTCPeerConnection({ iceServers: [{ urls: ['stun:stun.example.com'] } }); // 3. Add your local stream to the connection for (let track of localStream.getTracks()) { peerConnection.addTrack(track, localStream); } // 4. Exchange connection details with the server const offer = await peerConnection.createOffer(); const answer = await signalingServer.send({ offer }); await peerConnection.setLocalDescription(offer); await peerConnection.setRemoteDescription(answer); // 5. When the server sends you other participants' streams, display them peerConnection.ontrack = (event) => { const participantId = event.streams[0].id; displayRemoteVideo(participantId, event.streams[0]); }; } // SFU WebRTC: Single connection to server async function joinWebinar() { // 1. Get your webcam const localStream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true }); // 2. Create ONE peer connection (to the server, not to each participant) const peerConnection = new RTCPeerConnection({ iceServers: [{ urls: ['stun:stun.example.com'] } }); // 3. Add your local stream to the connection for (let track of localStream.getTracks()) { peerConnection.addTrack(track, localStream); } // 4. Exchange connection details with the server const offer = await peerConnection.createOffer(); const answer = await signalingServer.send({ offer }); await peerConnection.setLocalDescription(offer); await peerConnection.setRemoteDescription(answer); // 5. When the server sends you other participants' streams, display them peerConnection.ontrack = (event) => { const participantId = event.streams[0].id; displayRemoteVideo(participantId, event.streams[0]); }; } The WebRTC server The server not only coordinates connections between participants, it also enables selective forwarding of streams between participants. For a webinar with 100 participants, this means that each participant is not sharing their webcam stream 99 different times, they just upload 1 stream to the server and that gets forwarded around to everyone. Each of the 100 participants doesn’t also need to subscribe to 99 other video feeds, the application can apply business logic so that each participant only subscribes to a subset of available feeds (like maybe everyone gets the host’s webcam and screen-share, and 5 random other participant’s feeds), reducing bandwidth for everyone. WebRTC in practice WebRTC was built for video-conferencing and adjacent use cases like our webinar example, so it has become the defacto method for doing real-time video exchange even for non-browser platforms like Android & iOS. The main challenges for WebRTC include Scalability - Server-side forwarding of many simultaneous video streams requires significant CPU and bandwidth, making it increasingly expensive to scale beyond a certain point (usually thousands) Control - WebRTC was built primarily with video conferencing in mind, and so while it is highly optimized for that use case, it lacks fine-grained control over media encoding & delivery (codecs, strings, packet-level control) that are relevant in other use cases like remote control or AI video pipelines. Scalability - Server-side forwarding of many simultaneous video streams requires significant CPU and bandwidth, making it increasingly expensive to scale beyond a certain point (usually thousands) Scalability - Server-side forwarding of many simultaneous video streams requires significant CPU and bandwidth, making it increasingly expensive to scale beyond a certain point (usually thousands) Control - WebRTC was built primarily with video conferencing in mind, and so while it is highly optimized for that use case, it lacks fine-grained control over media encoding & delivery (codecs, strings, packet-level control) that are relevant in other use cases like remote control or AI video pipelines. Control - WebRTC was built primarily with video conferencing in mind, and so while it is highly optimized for that use case, it lacks fine-grained control over media encoding & delivery (codecs, strings, packet-level control) that are relevant in other use cases like remote control or AI video pipelines. What is Media over Quic? Media over Quic (MoQ) is a new protocol for streaming real-time video… kind of like WebRTC. And Media over Quic allows us to build real-time video applications like our webinar app, kind of like WebRTC… Okay, so but if WebRTC already exists and works just fine, why are companies like Cloudflare and Meta all of the sudden working on a new protocol? Cloudflare Meta Let’s first talk about QUIC Almost any normal sever communication you might deal with as a web developer takes the form of an HTTPS request, which involves a number of back and forth steps between a network and server to set up the connection. These HTTP requests, and APIs like Websockets and sometimes WebRTC, use a protocol called TCP, a protocol for exchanging data between a network and a server, where packets are sent in order. If a packet gets lost, subsequent packets get held up, which conserves order, but which can lead to “head of line blocking” QUIC is an alternative protocol, and acts more like fast courier that prioritizes speed, it can drop less important packages (like a video frame) but it means getting the rest of your delivery through faster. Some differences between QUIC and normal TCP/HTTP QUIC connections require less setup QUIC can drop individual packets intelligently instead of slowing down the whole connection QUIC can maintain a connection when switching between networks, like say switching from WIFI to a cellular connection QUIC connections require less setup QUIC can drop individual packets intelligently instead of slowing down the whole connection QUIC can maintain a connection when switching between networks, like say switching from WIFI to a cellular connection QUIC is therefore a useful networking protocol which is particularly well suited for streaming video, though in theory you can send any data over QUIC. Now that we have, QUIC, let’s send some Media over it The idea behind Media over Quic is, as you likely have already guessed, to send Media over QUIC connections. Specifically though, Media over Quic is a formalized protocol on top of QUIC. Media over Quic works as a pub/sub system where a publisher sends streams of encoded media to a relay (essentially a CDN), and subscribers receive those streams from the relay: publisher relay subscribers Media over Quic relays are content-agnostic, they don’t know what is going across the network, whether it’s video, audio, text or just random binary code. They also have no visibility as to whether it’s encrypted or not. Another key aspect is that Media over Quic relays can be chained together, so that some subscribers might receive data that has passed through just 1 relay, and others might receive data that has passed through 5 relays. Media over Quic relays also don’t need to maintain state of the overall “broadcast”, they just act as data-pipes without being aware of many publishers and subscribers there are or how long the session has been active. These are key features that enable Media over Quic to be run through CDNs, which enables real-time streaming to millions of viewers simultaneously, something which isn’t possible with WebRTC. CDNs Pseudocode examples To watch a stream, it Media over Quic would look something like this async function watchWebinarViaQuic() { // 1. Connect to the relay const connection = await Moq.connect("https://relay.moq.some-cdn.com"); // 2. Subscribe to the broadcast const broadcast = connection.consume("my-webinar"); // 3. Subscribe to the video and audio tracks const videoTrack = await broadcast.subscribe("video"); const audioTrack = await broadcast.subscribe("audio"); // 4. Decode and display/play the streams decodeAndDisplayVideo(videoTrack); decodeAndPlayAudio(audioTrack); } async function watchWebinarViaQuic() { // 1. Connect to the relay const connection = await Moq.connect("https://relay.moq.some-cdn.com"); // 2. Subscribe to the broadcast const broadcast = connection.consume("my-webinar"); // 3. Subscribe to the video and audio tracks const videoTrack = await broadcast.subscribe("video"); const audioTrack = await broadcast.subscribe("audio"); // 4. Decode and display/play the streams decodeAndDisplayVideo(videoTrack); decodeAndPlayAudio(audioTrack); } To broadcast a stream would look something like this: async function joinWebinarViaQuic() { // 1. Get your webcam const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true }); const videoTrack = stream.getVideoTracks()[0]; const audioTrack = stream.getAudioTracks()[0]; // 2. Connect to a MoQ relay (instead of connecting to an SFU) const connection = await Moq.connect("https://relay.moq.some-cdn.com"); // 3. Create a broadcast (namespace for your streams) const broadcast = new Moq.Broadcast(); connection.publish("my-webinar", broadcast); // 4. Get video and audio tracks from the relay const videoMoqTrack = await broadcast.requested('video'); const audioMoqTrack = await broadcast.requested('audio'); // 5. Stream your camera to the relay encodeAndStreamVideo(videoTrack, videoMoqTrack); encodeAndStreamAudio(audioTrack, audioMoqTrack); } async function joinWebinarViaQuic() { // 1. Get your webcam const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true }); const videoTrack = stream.getVideoTracks()[0]; const audioTrack = stream.getAudioTracks()[0]; // 2. Connect to a MoQ relay (instead of connecting to an SFU) const connection = await Moq.connect("https://relay.moq.some-cdn.com"); // 3. Create a broadcast (namespace for your streams) const broadcast = new Moq.Broadcast(); connection.publish("my-webinar", broadcast); // 4. Get video and audio tracks from the relay const videoMoqTrack = await broadcast.requested('video'); const audioMoqTrack = await broadcast.requested('audio'); // 5. Stream your camera to the relay encodeAndStreamVideo(videoTrack, videoMoqTrack); encodeAndStreamAudio(audioTrack, audioMoqTrack); } Actually encoding/decoding and displaying video involves a whole other thing called WebCodecs but there are also libraries that handle that.. WebCodecs libraries Streams vs Connections The fundamental architectural difference between WebRTC and Media over Quic is that WebRTC operates as a series of active stateful connections, whereas MoQ acts as a series of independent, parallel streams In WebRTC connections are inherently bidirectional (whether between peers or from client to server) whereas in MoQ operations with parallel independent unidirectional streams. Okay, but why MoQ? A number of companies and developers are excited about MoQ because it has concrete advantages compared to WebRTC (and other web video technologies). Scale: MoQ can deliver the same kind of real-time video experience as video conferencing software, but because streams are sent over CDNs, one person with a webcam can stream to millions of people, which would be impossible with WebRTC Scale: Efficient transport QUIC enables more reliable streaming, enabling connections to persist even when switching over networks (e.g. mobile to WIFI), and also enables dropping frames/packets to ensure real-time delivery. Efficient transport Simple model Because the infrastructure model is so simple, it greatly simplifies the networking stack while also simultaneously providing more low-level control over video encoding and decoding, which is important for some applications. Simple model Media over Quic in practice As of January 2026, Media over Quic is still in a very early stage, and relies on several components which are still being developed: WebTransport - the WebAPI that allows QUIC connections is supported by ~80% of browsers, but not yet supported on Safari Libraries: The core libraries for Media over Quic only exist for Rust (server) and JS (client), and there are no mobile SDKs yet Relays: Several CDN providers are creating MoQ relays, and Cloudflare already has one, but they are still in “beta”, and the most reliable method right now is hosting your own WebTransport - the WebAPI that allows QUIC connections is supported by ~80% of browsers, but not yet supported on Safari WebTransport Libraries: The core libraries for Media over Quic only exist for Rust (server) and JS (client), and there are no mobile SDKs yet Libraries: server client Relays: Several CDN providers are creating MoQ relays, and Cloudflare already has one, but they are still in “beta”, and the most reliable method right now is hosting your own Relays Cloudflare already has one hosting your own Media over Quic has enough tooling and support for early adopters to start building with it, but it still requires a lot of ‘DIY’ adaptations and implementations, and is still too early for a seamless developer experience. If you’re not particularly adventurous, then Media over Quic is not for you (not yet at least). That said, there was a time when people said the same thing about NodeJS. Developers (including me!) are working on the core libraries for Media over Quic, and companies are developing relays/hosted solutions, so expect MoQ to become more stable & production ready in the coming months/years. So will it replace WebRTC? For people in the real-time video space, Media over Quic has been a hot topic, with a lot of discussion on whether Media over Quic will replace WebRTC. I personally find both the hype and counter-hype a little much because Media over Quic hasn’t matured to the point where it’s fair to compare it to WebRTC. To the 5% of readers already knew about MoQ before coming to this article, you likely already came into this article with some kind of opinion on the answer, so feel free to comment or post your counterargument, I could use the SEO. For the other 5% of you who made it through the entire article (kudos!). You may not have a horse in this race, but I do want to point out that regardless, if you do work in web development, it’s probably a good thing to be aware of MoQ and that it’s a new up and coming standard for real-time media streaming. I’ve started helping out with development on MoQ libraries not because I have any particular interest or desire to replace WebRTC, but rather because I like WebCodecs and low-level control, and it’s cool to get on the ground floor of a new protocol. That said, some of my closest professional contacts are WebRTC experts (I previously ran a startup which an AI filters SDK targeted at WebRTC products) and as a developer, just looking at the MoQ documentation it’s clear that it’s still too raw and early for widespread use. Overall I don’t feel like I have a horse in this race, but I am interested in seeing things develop. WebCodecs startup So will it replace WebRTC? Maybe Maybe WebRTC has a well established ecosystem, and solved a problem that didn’t previously have a good solution. Unlike WebRTC, MoQ isn’t competing with “nothing”, it’s competing with an established, well-supported protocol. That said, MoQ has real benefits over WebRTC and other streaming technologies like HLS/DASH streaming, and so here are likely some use cases where MoQ’s advantages would provide a compelling case for early adopters: HLS/DASH streaming Too big for WebRTC, to small for HLS/DASH Too big for WebRTC, to small for HLS/DASH The sweet spot for early adopters would likely be application categories which are not well served either by WebRTC or by HLS/DASH (not real-time, but does achieve high scale) Some examples might include: Webinar software, where webinars need real-time interactivity but which also need to scale to thousands or tens of thousands of participants Broadcasting virtual events where speakers typically stream few=>many, but which often involve interactive Q&A Browser based live-streaming tools, which stream video from browsers to servers and other participants, while simultaneously streaming social media platforms like Facebook like or YouTube live Webinar software, where webinars need real-time interactivity but which also need to scale to thousands or tens of thousands of participants Broadcasting virtual events where speakers typically stream few=>many, but which often involve interactive Q&A Browser based live-streaming tools, which stream video from browsers to servers and other participants, while simultaneously streaming social media platforms like Facebook like or YouTube live More control and reliability than WebRTC More control and reliability than WebRTC Media over Quic would also be helpful in scenarios where robust video connections or low-level control of video delivery are required, such as in scenarios with remote camera feeds (security cameras, drones, remotely operated vehicles) or in real-time AI video pipelines. WebRTC is often used in these scenarios, but in these cases, the scale benefit of MoQ is irrelevant, the primary advantages would be from more robust connectivity of HTTP3/Quic and low-level frame control that make MoQ an attractive option. For everything else For everything else For everything else there’s Mastercard WebRTC. Mastercard If you are building standard cookie-cutter video conferencing, WebRTC is the clear better technology and there likely won’t be a use case where MoQ makes sense until/unless the MoQ ecosystem reaches the level of stability and maturity of WebRTC (possibly? but even then, it might take a while). More resources If you are curious about Media over Quic, WebRTC or just real-time media streaming in general, here are a few resources: Media over Quic Media over Quic If you want to learn more about Media over Quic, you can dig deeper on The official MoQ website. WebCodecsFundamentals, an open-source textbook with code examples The MoQ discord The official MoQ website. MoQ website WebCodecsFundamentals, an open-source textbook with code examples WebCodecsFundamentals The MoQ discord MoQ discord WebRTC WebRTC There are plenty of tutorials about WebRTC (web.dev, MDN) and you can also hear a few other WebRTC experts talking about MoQ vs WebRTC on WebRTCHacks. There is also a great discord community for WebRTC developers called PION. web.dev MDN WebRTCHacks PION
