What is Media over QUIC (MOQ)? The Complete 2026 Guide

Media over QUIC (MOQ, or MOQT in the draft text) is a new publish/subscribe protocol for moving live and on-demand media over the modern QUIC transport protocol. The short version is that MOQ tries to combine the scale of HTTP-based streaming with the responsiveness of real-time systems, without forcing publishers to maintain a separate stack for every use case. That matters in 2026 because the industry is converging on more interactive experiences: low-latency sports, live shopping, synchronized second-screen apps, cloud production, AI-assisted media workflows, and browser-native experiences that need low-latency media delivery at massive fan-out.

The problem MOQ solves

Today's media stack is fragmented because each incumbent protocol solves only part of the problem.

• HLS and DASH scale extremely well because they fit CDNs and caches, but their segment-oriented workflow adds latency and buffering. Even low-latency HLS and low-latency DASH are still built around chunking, playlist churn, and HTTP fetch cycles.
• WebRTC achieves superb interactivity, but large one-to-many delivery is operationally expensive. Stateful sessions, SFU complexity, bandwidth duplication, and browser-focused assumptions make it a poor fit for every broadcast-style workload.
• SRT and RIST are excellent for contribution links and managed transport, but they are not browser-native internet distribution protocols and they do not define the same relay-first pub/sub model that large-scale consumer delivery wants.
• RTMP remains useful for ingest in legacy workflows, but it is no longer a modern answer for large-scale distribution, browser playback, or flexible object-level prioritization.

The result is a painful architecture pattern: ingest with one protocol, process with another, distribute with HLS or DASH, and bolt on WebRTC when product teams demand interactivity. The MOQ protocol exists because that split is increasingly unnecessary. If media is already being produced as ordered chunks or objects, why not deliver it over a transport designed for priorities, multiplexing, partial reliability, and relay fan-out from the beginning?

How MOQ works

At a high level, Media over QUIC is a pub/sub protocol on top of QUIC or WebTransport. Instead of every viewer opening a direct media session to the origin, publishers announce content and subscribers request exactly the tracks or ranges they want. Relays sit between the two ends and forward or cache content efficiently.

Three ideas matter most:

1. QUIC as the transport base

MOQ is designed around QUIC features that older stacks had to reconstruct awkwardly:

• Independent streams reduce classic TCP head-of-line blocking across unrelated data.
• Native encryption and connection migration are already part of the transport.
• Priorities and partial reliability give applications more control over what must arrive and what can be skipped.
• WebTransport makes the browser path realistic without inventing a completely separate delivery model.

2. Publish/subscribe instead of URL polling

In HLS or DASH, players repeatedly fetch manifests and segments. In MOQ, producers publish named content and consumers subscribe to it. That changes the delivery model from "keep requesting the next file" to "stay attached to the live object stream I care about."

This is why MOQ feels more like a media-aware messaging fabric than a simple file transfer protocol. Subscribers can attach late, request ranges, and follow live updates without the constant control-plane overhead of playlist refreshes.

3. Track, group, and object hierarchy

The object model is the core abstraction you need to understand.

• A track is a named sequence of media data, such as a video rendition, an audio language, captions, metadata, or even non-media real-time data.
• A group is an ordered collection within a track, usually aligned to a meaningful media boundary such as a GOP or a chunk beginning at a keyframe.
• An object is the smallest delivery unit inside a group: a frame, chunk, metadata blob, init segment, or application-defined payload.

That track/group/object hierarchy is what makes MOQ more flexible than "just stream bytes." A relay can prioritize the newest objects, skip stale ones, cache whole groups, or fan out only the tracks a subscriber requested. A player can subscribe to video only, audio only, or multiple tracks at different buffering targets.

What relays do

Relays are not an afterthought in MOQ. They are the scaling strategy. A relay can accept published content upstream, serve many subscribers downstream, and optionally cache or prioritize data in between. That gives MOQ a CDN-friendly shape without forcing delivery back into segment-polling HTTP semantics.

This is the key architectural promise of Media over QUIC: WebRTC-like immediacy where you need it, relay-based scale where you need it, and object-aware delivery logic throughout.

MOQ vs. alternatives

Protocol	Best for	Typical latency profile	Browser-native path	Massive fan-out	Main weakness versus MOQ
MOQ	Interactive broadcast, large live events, cloud media, hybrid real-time distribution	Sub-second to a few seconds, application-tunable	Yes, via WebTransport	Strong in principle because relays are first-class	Still early; drafts and implementations are evolving
HLS	Mainstream OTT and VOD	Usually seconds, sometimes lower with LL-HLS	Yes	Excellent	Control-plane overhead and chunk latency are baked in
DASH	OTT streaming and device ecosystems	Usually seconds, sometimes lower with LL-DASH	Yes	Excellent	Similar trade-offs to HLS; not ideal for interactivity
WebRTC	Calls, conferencing, ultra-interactive media	Very low	Yes	Weak for very large audiences without complex SFUs	Harder to scale economically for broadcast fan-out
SRT	Contribution and backhaul	Low	No	Limited	Not a browser/web distribution protocol
RIST	Managed contribution transport	Low	No	Limited	Strong for contribution, not consumer-scale playback
RTMP	Legacy ingest	Low-ish ingest latency	No modern browser playback path	Poor for modern internet distribution	Obsolete for the distribution side of the stack

The practical way to think about it is simple:

• If you only need VOD or "good enough" live at internet scale, HLS or DASH remain the default.
• If you need many-way conferencing, WebRTC still wins.
• If you need contribution transport between controlled endpoints, SRT and RIST remain strong choices.
• If you need broadcast-scale interactivity, selective subscriptions, and relay-aware low-latency media delivery, MOQ is the protocol worth evaluating.

Current spec status

As of May 29, 2026, the core transport document is draft-ietf-moq-transport-18, published on May 12, 2026. It is an active working-group draft with Standards Track intent. The working-group documents page also shows active companion drafts for LOC (draft-ietf-moq-loc-02), MOQT Streaming Format (draft-ietf-moq-msf-00), Privacy Pass Authentication (draft-ietf-moq-privacy-pass-auth-02), Secure Objects (draft-ietf-moq-secure-objects-00), and CMSF (draft-ietf-moq-cmsf-00).

That matters because MOQ is no longer "one transport draft and some demos." It is becoming a stack:

• Transport defines the core publish/subscribe behavior.
• LOC defines a low-overhead media container aimed at interactive use.
• MSF/CMSF address streaming format and CMAF-compatible packaging.
• Privacy Pass auth and Secure Objects push the ecosystem toward deployable access control and end-to-end security.

The IETF moq working group milestone page still targets December 2026 for requesting publication of the transport draft to the IESG. That is not the same as "finished RFC in 2026," but it is the clearest public signal yet that the protocol is moving toward a real standards checkpoint.

Implementations

The implementation picture is healthy enough in 2026 to move MOQ out of the purely theoretical category. A few projects matter most:

1. cloudflare/moq-rs
   The best-known open implementation of the IETF-style transport today. It includes relay, publisher, subscriber, and transport components, and its README still points developers to browser playback workflows and compatibility notes.

2. moq-dev/moq
   A fast-moving Rust and TypeScript stack that includes relay, CLI, browser demos, and the @moq/net / @moq/lite client layers. This is the clearest answer if someone asks for a "moq-js" style implementation in 2026.

3. gmarzot/aiomoqt
   A serious Python implementation with both publish and subscribe roles, H3/WebTransport and raw QUIC support, and explicit dual-draft support useful for testing and interoperability work.

4. mengelbart/moqtransport
   An older but still useful Go implementation and reference point for engineers who want to study protocol behavior or small examples.

5. Historical quic.video ecosystem
   Early MOQ demos, documentation, and code around Luke Curley's work helped popularize the protocol before the current moq-dev stack became the center of gravity. If you still see developers mention quic.video, that is the lineage they mean.

This list is not exhaustive, but it is enough to show that the protocol is being exercised in Rust, TypeScript, Python, Go, browser environments, and real relay software.

Who is using MOQ

The honest answer is: public production claims are still limited, but public investment is now unmistakable.

• Meta, Google, and Cisco are directly visible in the core transport draft author/editor line.
• Microsoft appears on the LOC work.
• Akamai appears on MSF and CMSF.
• Cloudflare is building and operating public MoQ infrastructure and maintains moq-rs.

Cloudflare is the clearest public deployment signal so far because it has openly launched a MoQ relay network and described MoQ as a unifying foundation for large-scale interactive streaming. Outside that, most of the large-company evidence in 2026 is still "building, editing, standardizing, testing, or evaluating" rather than "we have fully replaced HLS."

That is normal for an emerging standards-based protocol. If you are looking for a simple mental model, use this one:

• Cloudflare is proving infrastructure appetite.
• Meta, Google, Cisco, Microsoft, and Akamai are proving standards and ecosystem appetite.
• Smaller vendors and specialist platforms are proving that there is commercial demand for earlier MoQ experimentation.

When to use MOQ

MOQ is a good fit when all of the following are true:

• You care about latency below traditional OTT streaming norms.
• You need large audience fan-out or relay-based distribution.
• You want more control than WebRTC usually gives you over quality, buffering, prioritization, or selective subscription.
• You expect the browser to matter.

Strong candidate use cases include:

• live sports with synchronized data overlays,
• live auctions and betting,
• cloud production and remote contribution workflows,
• watch parties and multi-view experiences,
• real-time AI or metadata streams alongside audio/video,
• large live events where WebRTC cost and state become painful.

MOQ is probably not your first choice if you just need ordinary VOD, if you need the most mature device compatibility today, or if your main workload is many-to-many conferencing rather than one-to-many or few-to-many distribution.

Getting started

If you want to evaluate the protocol seriously, start here:

• IETF working group: https://datatracker.ietf.org/wg/moq/about/
• Working-group documents: https://datatracker.ietf.org/wg/moq/documents/
• Core transport draft: https://datatracker.ietf.org/doc/draft-ietf-moq-transport/
• WG source repos: https://github.com/moq-wg
• Cloudflare Rust stack: https://github.com/cloudflare/moq-rs
• moq-dev Rust + TypeScript stack: https://github.com/moq-dev/moq
• Python implementation: https://github.com/gmarzot/aiomoqt
• Mailing-list archive: https://mailarchive.ietf.org/arch/browse/moq/

The most practical evaluation path is to read the transport draft, run a relay locally, publish a simple media source, and then compare MOQ against your current HLS, WebRTC, or SRT workflow on latency, scaling model, and operational complexity.

FAQ

Is Media over QUIC the same thing as WebRTC?

No. Both can support real-time media, but WebRTC is optimized around interactive sessions and peer/session semantics, while Media over QUIC is optimized around publish/subscribe distribution with relays and object-aware delivery.

Is the MOQ protocol finished?

No. The protocol is much further along than it was in 2024 or 2025, but it is still defined by active IETF drafts. In 2026 you should treat it as an emerging standard with real implementations, not a frozen legacy standard.

Does MOQ replace HLS and DASH?

Not immediately. HLS and DASH are still the default answers for VOD and mainstream OTT. MOQ becomes interesting when latency, interactivity, selective subscription, or relay-aware fan-out are strategic product requirements.

Is MOQ browser-friendly?

Yes, that is one of its biggest advantages. Because the protocol is designed to work over WebTransport as well as QUIC, it has a credible web path that SRT, RIST, and RTMP do not.

What does the IETF moq working group actually do?

It standardizes the transport and companion pieces needed to make MOQ deployable: transport behavior, media formats, packaging, authentication, and related extensions. If you care about "MOQ IETF" progress, this is the venue that matters.

Why do some people say MoQ and others say MOQT?

MoQ usually refers to the overall effort or ecosystem, while MOQT is often used in the draft text for the transport protocol itself. In practice, most engineers use "Media over QUIC" or "MOQ" in conversation.

Is MOQ only for video?

No. The protocol is media-oriented, but the object model is flexible enough for audio, captions, metadata, timed control data, and other real-time payloads. That is part of why it keeps showing up in adjacent application ideas beyond classic streaming.

Should I build on MOQ in 2026?

If you are experimenting with next-generation live infrastructure, yes. If you need the safest mainstream deployment choice for mass-market playback today, probably not yet. The right move for most teams is a pilot, not an all-in rewrite.