For years, developers building real-time video and audio applications on the web have worked under a quiet constraint: whatever protocol you chose, it had to work in Safari.
Well, that’s not 100% true because many WebRTC apps used to have disclaimers like “works best in Chrome”. When Safari finally fully supported WebRTC, it was a happy day for WebRTC developers. We could stop asking users “what browser are you using?” when responding to bug reports.
Okay, that’s not completely true either because bugs can still be dependent on a specific browser. But at least WebRTC was finally completely supported across all the major browsers and mobile operating systems.
Until very recently, that was not true for WebTransport. So anyone building for the open web (and especially for iOS mobile) was probably going to avoid working with WebTransport. That constraint is gone.
WebTransport Is Now Baseline in Safari
As of March 2026, Safari 26.4 ships WebTransport out of the box. No flags, no workarounds. Chrome, Firefox, and Edge already had it. The result is that WebTransport has crossed into Baseline status, which is the web platform’s designation for features that work across all major browsers and are safe to use in production.
This is a meaningful inflection point for anyone building voice, video, or real-time data applications on the web. Let’s unpack why.
I had an interesting conversation with Tsahi Levent-Levi about this when the news came out. This conversation is on the WebRTC.ventures YouTube Channel: WebTransport in Safari!
What Is WebTransport and How Does It Work?
WebTransport is a browser API for low-latency, bidirectional communication between a web client and a server, built on HTTP/3 and the QUIC protocol. Think of it as what you would get if you took WebSockets, replaced the TCP foundation with QUIC, added stream multiplexing, and gave developers the choice between reliable and unreliable delivery. And you can do all of this on the same connection for multiple streams.
Here are the key capabilities that matter for media work:
- Multiple independent streams over a single connection, so a dropped packet on one stream does not stall another
- Unreliable datagrams for sending data where you would rather drop a stale frame than buffer it
- Reliable streams for control messages and metadata that must arrive intact
- HTTP/2 fallback when QUIC is not available in the network path
Why Safari Support Was a Big Deal for WebTransport
On desktop, Chrome and Firefox are genuine alternatives to Safari. On iOS, they are not. Every browser on an iPhone or iPad is required to use Apple’s WebKit engine.
Safari blocking WebTransport did not just mean Safari users could not use your app. It meant every iOS user could not use your app. That is roughly a billion devices, so it’s good to see Apple close that gap on Safari.
Why WebTransport Matters for Real-Time Media
You can now build server-centric media architectures without WebRTC’s peer-to-peer overhead. (Where it makes sense.)
WebRTC is great. We love it and most video and voice applications will continue to use WebRTC as the protocol of choice. WebRTC is also great for Voice AI Architectures!
But let’s be honest. WebRTC was designed for peer-to-peer communication and it still shines best in its original use cases: small conversations and “meeting tool” scenarios.
Its connection establishment process reflects this: you need ICE negotiation, STUN servers to discover public IP addresses, TURN servers to relay traffic when direct connections fail, and a signaling layer that has to run before any media flows at all. This infrastructure can be expensive to operate and complex to debug.
See our three part series on Networking Basics for WebRTC for more on this topic.
WebTransport vs WebRTC: When Each Makes Sense
These are all powerful parts of the WebRTC stack, and for most use cases they are the right choice. SFUs, whether open source or commercial, also make the media-server side of WebRTC much more manageable. But there are still some scenarios where the overhead of a peer-to-peer architecture is not the best fit.
That is where WebTransport starts to make more sense. For client-server use cases, it gives you more control over the media pipeline end to end, but it also means taking on more of the complexity yourself. This may include:
- Some Voice AI agent use cases
- Some IoT and device data streaming applications
- Large live streams
- Some interactive video broadcasts
An architecture based on WebTransport (or eventually MOQ) may fit these use cases more naturally. WebTransport gives you more control of the media pipeline end-to-end, but you also have to do more work. With extra power comes additional development complexity!
WebRTC’s built-in media stack is a blessing for rapid development. It resolves a lot of complexity through its codec negotiation, echo cancellation, and bandwidth estimation. But if you want to use a codec the browser’s WebRTC stack does not support? Want to insert a custom AI noise suppression model? Want to implement your own adaptive bitrate logic? You end up fighting the stack.
WebTransport, paired with the WebCodecs API, gives you the full pipeline control that WebRTC does not. You can capture raw frames, encode them yourself, transmit over WebTransport, and decode on the other end. Every stage is under your control.
When WebRTC Is Still the Better Choice
For small-group video conferencing, what you might call the Zoom and Google Meet use case, WebRTC remains the stronger choice today, and likely for some time.
Congestion control in multi-party video is a deeply solved problem in WebRTC. Algorithms like Google Congestion Control took years of engineering and field testing to tune properly. They handle the feedback loops between bandwidth estimation, packet loss, and encoder bitrate adaptation that keep a six-person video call watchable when one participant’s network degrades. WebTransport does not have equivalent algorithms yet.
WebRTC also brings built-in echo cancellation, noise suppression, and automatic gain control. These capabilities that you get for free would need to be implemented separately in a WebTransport-based media pipeline.
The honest summary: for interactive, small-group conferencing, WebRTC’s decade of production hardening is a real advantage. For client-server media at scale, WebTransport may become a more natural fit. And that’s why it’s a big deal that Safari now supports WebTransport also.
How MOQ Fits on Top of WebTransport
A natural follow-up question when WebTransport reaches Baseline: what about MOQ (or as it was originally called, Media over QUIC)? WebTransport and MOQ are related but distinct. The distinction matters.
WebTransport is the transport primitive. MOQ is a full media delivery protocol built on top of it, with its own concepts of publishers, subscribers, tracks, groups, and relay nodes. The relationship is similar to TCP and HTTP: having TCP does not mean you have HTTP.
The protocol stack looks like this:
- MOQ (moq-transport): The application protocol, handling pub/sub, tracks, and relay logic
- WebTransport: The browser transport API, providing the QUIC connection
- HTTP/3 / QUIC: The underlying network protocol
Safari shipping WebTransport removes a blocker for MOQ-based web applications running in Safari but the remaining complications are real. The MOQ spec is still an IETF draft, currently at draft-17 as of March 2026, and has not yet been published as an RFC. The ecosystem is forming rapidly, but it’s still a work in progress and MOQ is not fully available yet.
The Bottom Line on MOQ
WebTransport reaching Baseline unlocks the foundation MOQ needs to run everywhere. But MOQ itself is still maturing, both in spec stability and in the WebCodecs dependency. Production MOQ deployments are happening today in controlled environments. But the universal browser-based MOQ is a 2026 to 2027 story.
MOQ is a fascinating topic that we’ve discussed before on WebRTC Live. For more expert opinions, check out: WebRTC Live Episode 102: “MOQ me, don’t WebRTC me” with Ali C. Begenand WebRTC Live Episode 107: “WebRTC vs MoQ: A Panel Discussion with Cloudflare” with Cloudflare Engineers Renan Dincer, Mike English, and Nils Ohlmeier.
What Should Video and Voice Developers Do Now That WebTransport Is Baseline?
If you are maintaining a WebRTC-based application today, you do not need to rewrite anything. WebRTC is still the right foundation for multi-party conferencing. Its maturity in that domain is a genuine advantage.
If you are starting something new and your use case is more suited to client-server rather than peer-to-peer, WebTransport is now a first-class option for the full browser landscape.
Our team at WebRTC.ventures is watching this space closely and will continue to write about how WebTransport and MOQ evolve in practice. If you are building something in this area and want to build a prototype on the latest tech, reach out! This is exactly the kind of work we love. We can also help you sort out which media architecture will be best for your specific needs. Contact us today!
