Media over QUIC — MoQ — is the most discussed emerging streaming protocol of 2025-2026. Blog posts multiply, conference talks pile up, and CDN vendors are racing to announce support. If you work in live streaming, you have probably been asked: should we switch to MoQ?
The short answer, for most products shipping today, is no — not yet. But MoQ is worth understanding, because the problems it solves are real, and the timeline for it becoming production-ready is now measured in quarters, not years.
This article explains what MoQ actually is, where it stands as of March 2026, what it changes compared to HLS, WebRTC, and SRT — and whether it would make sense for two real-world products we have deployed: WeSpeakSports (live fan audio commentary over WebRTC) and DJing Stream (broadcast-grade DJ audio over SRT and HLS Lossless).
What MoQ actually is
MoQ stands for Media over QUIC. It is an IETF working group effort started in 2022, to define a new media delivery protocol built on top of QUIC (the transport layer behind HTTP/3).
The core transport specification, draft-ietf-moq-transport, reached version 17 in March 2026. A streaming format spec (draft-ietf-moq-msf) is also in progress, along with companion drafts for CMAF packaging and header compression. None of these are finalized RFCs yet.
At its core, MoQ is a publish/subscribe protocol. A publisher sends named media objects (audio frames, video frames, metadata) to relays, and subscribers receive them by subscribing to named tracks. This is fundamentally different from both HLS (HTTP request/response for segments) and WebRTC (peer-to-peer session negotiation with SDP/ICE).
MoQ runs over QUIC streams and datagrams, either natively or via WebTransport (the browser API for QUIC). This gives it access to QUIC's multiplexing, prioritization, and partial reliability features — meaning the protocol can, by design, drop a late video frame rather than stall the entire stream waiting for retransmission.
What MoQ is trying to replace
As Cullen Jennings from Cisco (a MoQ working group participant) puts it, the streaming world currently has two silos. On one side, services like Netflix and YouTube deliver media at scale through HTTP-based CDNs, but with seconds of latency. On the other side, conferencing tools like Zoom and WebRTC-based platforms deliver media in near-real-time, but cannot scale cost-effectively to large audiences.
MoQ aims to bridge these two worlds with a single protocol that can serve both real-time and near-real-time use cases, from contribution (ingest) through distribution (delivery to viewers), with CDN-compatible relay infrastructure in between.
Where MoQ stands today (March 2026)
Let's be precise about the current state:
The specification is close but not done. The transport draft is at version 17, iterating rapidly. The streaming format draft was published in January 2026. There is active companion work on CMAF packaging and header compression. But there is no ratified RFC yet.
The Safari/WebTransport gap is closing. MoQ in the browser depends on WebTransport, which requires HTTP/3 and QUIC. Chrome and Firefox already support WebTransport. Safari was the holdout — but Apple added WebTransport support in Safari 26.4 beta (February 2026), and it is an official Interop 2026 commitment from WebKit. As of March 2026, this has not yet shipped in a stable Safari release, but it is no longer a question of if — only when in the next OS cycle. For products targeting iPhone and iPad users through a browser, the gap is nearly closed.
Early production deployments exist but are limited. Nanocosmos demonstrated end-to-end MoQ delivery (OBS ingest to global audience) at the MonteVIDEO Summer Project. Cloudflare launched a MoQ beta. Red5 announced MoQ support coming by end of 2026. But these are early-adopter deployments, not mainstream infrastructure.
The community is honest about maturity. Even Luke Curley, who built one of earliest MoQ implementations at Twitch (now Discord) and authored the moq-lite simplification draft, explicitly states that the full MoQ transport spec "has become too complicated" with "too many messages, optional modes, and half-baked features." His moq-lite draft is a response to this complexity.
Industry veterans are measured. Tsahi Levent-Levi of BlogGeek.me predicted that in 2026, developers would complain more about WebRTC than MoQ — not because MoQ is better, but because MoQ users are still early adopters who expect rough edges. WebRTC is the one in production everywhere, bearing the weight of real-world expectations.
What MoQ changes compared to HLS
HLS (HTTP Live Streaming) works by splitting media into segments, writing them to an HTTP server, and having players poll for new segments via playlists. It is mature, CDN-friendly, broadly deployed, and well-documented in RFC 8216 and Apple's HLS Authoring Specification. Low-Latency HLS (LL-HLS) pushes latency down to roughly 2-4 seconds.
MoQ changes the delivery model in several ways:
From polling to push. HLS players request segments. MoQ subscribers receive objects as they are published. This eliminates polling latency.
From segments to objects. HLS operates on multi-second segments (or partial segments in LL-HLS). MoQ can operate at the frame level. A single video frame or audio frame can be an individually addressable, individually deliverable object.
From TCP to QUIC. HLS runs over HTTP/TCP. When a TCP packet is lost, everything behind it stalls (head-of-line blocking). MoQ runs over QUIC, where streams are independent — a lost packet on one stream does not block others.
Explicit prioritization. MoQ's transport draft defines priority and delivery order at the protocol level. During congestion, a relay can drop lower-priority objects (e.g., B-frames) rather than delaying everything equally.
Unified ingest and distribution. Today, most live workflows use one protocol for contribution (RTMP, SRT, WHIP) and another for distribution (HLS, DASH). MoQ can potentially serve both paths with a single protocol, eliminating the repackaging step at the origin server.
When HLS still wins
None of this means HLS is obsolete. HLS remains the stronger choice when:
- A few seconds of latency are perfectly acceptable
- Broad device compatibility is essential (every phone, TV, and set-top box plays HLS)
- The existing CDN and tooling investment is working well
- Operational simplicity and battle-tested reliability matter more than pushing latency lower
For standard OTT live and VOD delivery — which is the overwhelming majority of streaming traffic — HLS is not broken, and MoQ does not fix a problem that exists.
What MoQ changes compared to WebRTC
WebRTC was designed for real-time peer-to-peer communication: video calls, screen sharing, one-to-one or small-group conversations. The industry has stretched it well beyond that original scope, using SFU (Selective Forwarding Unit) architectures to scale WebRTC to larger audiences.
MoQ differs from WebRTC in several important ways:
Architecture. WebRTC is fundamentally a session-oriented peer-to-peer protocol, even when mediated through SFUs. MoQ is a client-server publish/subscribe protocol designed around relays and CDN-style distribution from the start.
Scalability model. Scaling WebRTC requires SFU infrastructure that is purpose-built and expensive. MoQ relays are designed to integrate with existing CDN infrastructure — HTTP/3 servers can be extended to handle MoQ traffic, which is why CDN vendors like Akamai and YouTube are actively involved.
Complexity. WebRTC carries significant complexity: SDP offer/answer negotiation, ICE candidate gathering, STUN/TURN servers for NAT traversal, SRTP for encryption, SCTP for data channels. MoQ's connection setup is simpler — a QUIC handshake followed by subscribe/publish messages.
Codec flexibility. WebRTC's codec negotiation is tightly coupled to the protocol. MoQ is codec-agnostic at the transport level — media format is handled by the application layer (MSF, LOC, or custom containers).
Browser dependency. Both protocols depend on browser APIs for web-based delivery. WebRTC has universal browser support. MoQ depends on WebTransport, which Safari has only just added in beta (26.4, February 2026) and has not yet shipped stable. This gap is closing but still a practical consideration for MoQ today.
When WebRTC still wins
WebRTC remains the better choice when:
- True bidirectional real-time communication is needed (video calls, conferencing)
- Browser compatibility across all platforms including Safari/iOS is required
- The use case is peer-to-peer or small-group with no need for CDN-scale distribution
- Proven, production-grade tooling and SDK maturity matters
What MoQ changes compared to SRT
SRT (Secure Reliable Transport) excels at moving high-quality media from point A to point B over unpredictable networks. It provides AES encryption, packet loss recovery via ARQ (Automatic Repeat Request), and adaptive bitrate support. SRT is widely adopted for ingest workflows (cameras to studios, remote production to cloud encoders) but also serves as a point-to-point distribution protocol — as DJing Stream demonstrates.
MoQ and SRT serve overlapping but different purposes:
SRT is point-to-point; MoQ is publish/subscribe. SRT connects one sender to one receiver. MoQ natively supports one-to-many distribution through relays.
SRT guarantees delivery; MoQ can choose not to. SRT's ARQ mechanism retransmits every lost packet, which ensures lossless delivery but adds latency under packet loss. MoQ can be configured for partial reliability — dropping late objects instead of retransmitting them — which is better for live latency-sensitive delivery but unacceptable when every sample matters.
SRT is mature and deployed; MoQ is emerging. SRT has broad hardware and software support (OBS, vMix, FFmpeg, Haivision, every major encoder). MoQ has early-stage implementations.
When SRT still wins
SRT is the stronger choice when:
- The use case is point-to-point (source to encoder, encoder to origin, or direct-to-venue distribution)
- Lossless delivery matters more than absolute minimum latency
- The workflow involves professional broadcast equipment that already speaks SRT
- Audio fidelity at the bit level is non-negotiable
Case study: WeSpeakSports — live fan commentary over WebRTC
WeSpeakSports is a live fan audio commentary platform. Fans create or listen to real-time audio commentary during sports matches — football, basketball, rugby, F1, and more. The app is available on iPhone, iPad, Mac (Apple Silicon), and Vision Pro.
The current architecture uses WebRTC for audio streaming. A fan commentator broadcasts audio from their device, and listeners receive it in near-real-time. The audio is voice-quality, not music-quality — intelligibility and low latency matter far more than audiophile fidelity.
Would MoQ make sense for WeSpeakSports?
In theory, yes — it is an excellent fit for this use case. WeSpeakSports is a 1-to-many live audio broadcast with real-time expectations. This is precisely the gap MoQ is designed to fill: too many listeners for efficient WebRTC scaling, but too latency-sensitive for HLS.
MoQ's publish/subscribe model maps naturally to the WeSpeakSports architecture: a commentator publishes an audio track, listeners subscribe to it, and CDN relays handle distribution. This would be simpler and cheaper to scale than WebRTC SFU infrastructure.
In practice, not yet — for two hard reasons:
- Safari/iOS is almost there, but not yet. WeSpeakSports requires iOS 18.0. The app's primary audience is on iPhone. MoQ in the browser depends on WebTransport, which Apple added in Safari 26.4 beta but has not yet shipped in a stable release. Even for native iOS apps, there is no production-ready MoQ SDK for Apple platforms today. The WebRTC stack on iOS (via Apple's built-in WebKit support and mature third-party SDKs) is proven and works.
- Maturity. WeSpeakSports is a shipped product with real users. Swapping the transport layer from a proven protocol to a pre-1.0 specification would be premature. WebRTC is handling the current scale. The complexity cost of migrating is not justified by the current user base.
When to revisit
MoQ becomes worth evaluating for WeSpeakSports when:
- WebTransport ships in stable Safari — which is now imminent given the Safari 26.4 beta — and a mature native MoQ SDK for iOS/macOS emerges
- The user base grows to a scale where WebRTC SFU costs become a meaningful constraint
- MoQ relay infrastructure is available from at least two CDN providers with SLA commitments
- The MoQ transport specification reaches RFC status
At that point, MoQ could meaningfully simplify the distribution architecture and reduce per-listener cost. The commentator-to-relay-to-listeners model is a textbook MoQ use case. It is a matter of timing, not fit.
Case study: DJing Stream — broadcast-grade DJ audio over SRT
DJing Stream is a macOS app designed for a very specific use case: streaming broadcast-grade audio from a DJ's setup to a venue's sound system, over the internet, in real time. The architecture prioritizes audio quality above everything else.
The current stack uses SRT for real-time distribution — delivering 24-bit PCM stereo audio at 48 kHz (approximately 2.3 Mbps) from the DJ's Mac to the venue's sound system. For wider distribution to remote listeners, the audio can also be served over HLS with lossless audio. The entire design philosophy is that a DJ's audio deserves the same fidelity as a physical cable connection.
Would MoQ make sense for DJing Stream?
No — and this is not a timing question. MoQ is fundamentally misaligned with DJing Stream's requirements.
Here is why:
- Lossless delivery is non-negotiable. DJing Stream sends uncompressed PCM audio. Every sample matters. SRT's ARQ retransmission guarantees that every packet arrives — it will add latency under loss rather than drop audio. MoQ's partial reliability model, which is one of its key advantages for live video, is exactly the wrong tradeoff for broadcast-grade audio. A dropped audio frame is an audible glitch on a club sound system. That is not acceptable.
- Point-to-point is the primary use case. The core DJing Stream scenario is one DJ streaming to one venue. This is a point-to-point link, not a distribution problem. MoQ's publish/subscribe relay model adds complexity without benefit for this topology.
- No browser requirement. DJing Stream is a native macOS app connecting to venue hardware. There is no web browser in the loop. The WebTransport/Safari gap is irrelevant, but so is MoQ's main advantage of browser-native delivery.
- SRT is already the right tool. SRT was designed for exactly this: reliable, encrypted, low-latency transport of high-quality media over unpredictable networks. It is battle-tested in broadcast production. Every encoder and media server speaks it. Replacing SRT with MoQ for the DJ-to-venue distribution link would mean giving up guaranteed delivery for no meaningful gain.
- HLS Lossless handles the distribution side. For the secondary use case of distributing to a wider audience (web listeners), HLS with lossless audio codecs is proven and compatible with every device. The latency tolerance for remote listeners is higher than for the venue itself, so HLS's segment-based model is perfectly adequate.
When to revisit
Honestly? Probably never for the core DJ-to-venue link. SRT does exactly what DJing Stream needs, and MoQ's design goals (scalable distribution with acceptable quality loss under congestion) are opposed to DJing Stream's design goals (zero-loss delivery of every audio sample).
The only scenario where MoQ might become relevant for DJing Stream is if the product expands toward large-scale fan distribution with lower fidelity expectations — for example, streaming a compressed version of a DJ set to thousands of listeners simultaneously. Even then, HLS or LL-HLS would likely remain simpler and more broadly compatible.
The decision framework
After researching MoQ extensively — the IETF drafts, industry commentary from Broadpeak, Red5, BlogGeek.me, webrtcHacks, Meetecho, and Nanocosmos — here is the simplest decision rule I can offer:
Keep your current stack when
- Your product ships today and your current protocol works
- You need Safari/iOS browser support today (WebTransport is in Safari beta but not yet stable)
- A few seconds of latency are acceptable (→ HLS/LL-HLS)
- You need guaranteed lossless delivery (→ SRT)
- You need true bidirectional real-time communication (→ WebRTC)
Start evaluating MoQ when
- Ultra-low latency to large audiences is core to your product value (live betting, auctions, synchronized second-screen experiences)
- You control the full stack from ingest to playback and can absorb a new protocol
- WebRTC scaling costs are becoming a real business problem
- You are building a new product that will not ship until late 2026 or 2027
- You can accept that the spec may still change before reaching RFC
Watch MoQ closely if
- You operate CDN or relay infrastructure (MoQ is designed to work with HTTP/3 CDNs)
- You build live sports products with synchronization requirements
- You want to converge ingest and distribution onto a single protocol
- You are frustrated by the repackaging overhead of RTMP/SRT ingest → HLS distribution
The bottom line
MoQ is real, it is well-designed, and it addresses genuine limitations in today's streaming protocol landscape. The ambition — one protocol for both real-time and near-real-time, from ingest to distribution, with CDN-scale relay support — is compelling.
But ambition is not the same as readiness. The specification is not finalized. Safari has WebTransport in beta but not yet in a stable release. Production deployments are limited to early adopters. The ecosystem of SDKs, tools, and operational knowledge that makes HLS, WebRTC, and SRT reliable in production simply does not exist yet for MoQ.
For most streaming products shipping in 2026, MoQ is something to track — not something to adopt. When it matures, and it will, it has the potential to simplify architectures that currently stitch together multiple protocols with repackaging layers in between.
Until then: if HLS works for your delivery, keep it. If WebRTC works for your real-time needs, keep it. If SRT works for your point-to-point links, keep it. The best protocol is the one that is shipping and working, not the one that is most exciting on a conference slide.
Sources
- IETF MoQ Transport draft (v17, March 2026): datatracker.ietf.org/doc/draft-ietf-moq-transport
- IETF MoQ Charter: datatracker.ietf.org/group/moq/about
- moq-lite draft: ietf.org/archive/id/draft-lcurley-moq-lite-02.html
- IETF Blog — What's the deal with MoQ: ietf.org/blog/moq-overview
- BlogGeek.me — MOQ: How it will redefine realtime media: bloggeek.me/moq-redefine-realtime
- webrtcHacks — WebRTC vs. MoQ by Use Case: webrtchacks.com/webrtc-vs-moq-by-use-case
- RFC 8216 (HLS): rfc-editor.org/rfc/rfc8216.html
- Apple HLS overview: developer.apple.com/streaming
- WebKit — Announcing Interop 2026 (WebTransport commitment): webkit.org/blog/17818/announcing-interop-2026
- MoQ CDN — Open-source MoQ CDN relay infrastructure: moqcdn.net
- Erik Herz on LinkedIn: linkedin.com/in/erikherz