WHIP vs. WHEP: The 2026 Guide to Sub-Second Latency in WebRTC

If you have ever tried to stream live video and found yourself shouting at the screen because the action you are watching happened five seconds ago, you already understand why WebRTC exists. WebRTC is the technology that makes real-time video possible in a browser, and it is the reason you can have a video call on Google Meet or watch a live stream with almost no delay.

The problem is that WebRTC was never designed to be easy for broadcasters. It was built for person-to-person calls, not for one person streaming to thousands of viewers. That is where WHIP and WHEP come in. These two protocols are changing how live video works on the web, and if you are building anything that involves real-time video, you need to understand them.

In this guide, I will explain what WHIP and WHEP are, how they differ, what kind of latency you can actually expect, and how to start using them today. No jargon, no fluff. Just plain English.

The Latency Problem WebRTC Solves

Before we talk about WHIP and WHEP, let us talk about why WebRTC matters in the first place.

Traditional live streaming uses protocols like RTMP for getting video into a server and HLS for sending it out to viewers. This works fine for many situations, but it comes with a big downside: latency. When you stream with RTMP and HLS, viewers can be anywhere from five to thirty seconds behind the broadcaster. For a pre-recorded event or a one-way broadcast, that delay might be acceptable. For anything interactive, it is not.

WebRTC was built to solve this. Instead of waiting for video to be packaged into chunks and delivered through a CDN, WebRTC sends media directly between peers using UDP. The result is latency that is typically under 500 milliseconds and often much lower. That is fast enough to feel real-time.

The catch is that WebRTC was designed for peer-to-peer connections, not for broadcasting. It requires a signaling mechanism to set up the connection, and every platform that used WebRTC invented its own way of doing that. This made it painful to integrate WebRTC into broadcast workflows. An encoder had to have a custom integration for every cloud service. A player needed a new signaling client for every WebRTC server.

WHIP and WHEP are the standards that fix this problem.

What Is WHIP?

WHIP stands for WebRTC-HTTP Ingestion Protocol. In plain English, it is a standard way for an encoder or a browser to send a WebRTC stream into a media server.

Here is how it works. The client (your encoder, your browser, or your streaming software) sends an HTTP POST request to a WHIP endpoint. That request contains something called an SDP offer, which is basically a description of the media the client wants to send. The server responds with an SDP answer and creates a session. After that, the actual media flows over WebRTC using ICE, DTLS, and SRTP. The signaling is done with simple HTTP requests.

The beauty of WHIP is its simplicity. One configured endpoint. One HTTP POST for setup. One HTTP DELETE to end the session. Bearer token authentication if you need it. That pattern fits encoders, contribution tools, and cloud media services.

WHIP reached full RFC status in March 2025 as RFC 9725. That matters because it means WHIP is no longer a draft or an idea. It is a published standard that broadcast teams can build on with confidence.

What Is WHEP?

WHEP stands for WebRTC-HTTP Egress Protocol. If WHIP is about getting video into a server, WHEP is about getting video out of a server and into a viewer's browser.

The idea is almost identical to WHIP, but the direction is reversed. A viewer's browser sends an HTTP POST request to a WHEP endpoint. That request contains an SDP offer. The server responds with an SDP answer and starts sending media. The media flows over WebRTC, and the viewer sees the stream with sub-second latency.

WHEP is useful because playback is where WebRTC meets real users. Those users do not care about SDP, ICE candidates, or codec negotiation. They care that the preview opens quickly, stays live, and does not require a custom client for every service.

There is one important difference between WHIP and WHEP that you should know about. As of 2026, WHEP is still an Internet-Draft, not a finished RFC. The IETF WISH working group has been drafting WHEP since 2022, but the document has not yet progressed to RFC status. That does not mean WHEP is not usable. Many major platforms support it. But it does mean you should verify WHEP support in the products you plan to use.

WHIP vs. WHEP: The Key Differences

Let us put them side by side.

FeatureWHIPWHEPFull nameWebRTC-HTTP Ingestion ProtocolWebRTC-HTTP Egress ProtocolDirectionInto the server (ingest)Out of the server (playback)Who uses itEncoders, browsers, streaming softwareViewers, players, monitoring appsStandard statusRFC 9725 (published March 2025)Internet-Draft (still in progress)HTTP methodPOST to start, PATCH for ICE, DELETE to stopPOST to start, DELETE to stopAuthenticationBearer tokenBearer tokenMedia transportWebRTC (ICE, DTLS, SRTP)WebRTC (ICE, DTLS, SRTP)

The most important thing to understand is that neither WHIP nor WHEP makes your video faster. Both are signaling protocols. They handle the setup and teardown of a WebRTC session. The actual latency comes from WebRTC itself. Anyone who tells you that WHIP gives you "sub-100 ms latency" is describing WebRTC and putting the wrong label on it.

The Truth About Sub-Second Latency

Now we come to the part that most articles get wrong. What kind of latency can you actually expect when you use WHIP and WHEP?

The marketing answer is "sub-second." The real answer is more nuanced.

Independent testing has found that CDN-delivered WebRTC often lands somewhere between 0.58 and 1.30 seconds. The practical advice is to budget for 0.6 to 1.3 seconds and treat anything faster as a gift.

Some platforms advertise less than 500 milliseconds of latency for WebRTC playback. That is achievable under good network conditions and with a well-optimized pipeline. But it is not guaranteed for every viewer in every situation.

There is also a useful comparison from open-source streaming servers. They found that using OBS with WHIP can achieve around 200 milliseconds of latency, compared to approximately 500 milliseconds when using RTMP combined with WebRTC playback. Separate benchmarks have measured WHIP ingest at around 108 milliseconds and SRT ingest at around 386 milliseconds.

So what should you plan for? If you are building a live streaming product with WHIP and WHEP, aim for 200 to 800 milliseconds of glass-to-glass latency in production. That is genuinely real-time for most interactive use cases. If you need lower than that, you are moving into territory where you need to control every part of the pipeline, including the network between the encoder and the server.

How to Use WHIP and WHEP in Practice

Now let us get practical. How do you actually use these protocols?

Setting Up WHIP with OBS

OBS Studio, the most popular streaming software, supports WHIP natively. Here is how to set it up.

Open OBS and go to Settings. Click on the Stream tab. In the Service dropdown, select WHIP. You will see a field for the Server URL and a field for a Bearer token. Enter the WHIP endpoint URL provided by your streaming service. If your service requires authentication, paste the token into the Bearer token field. Leave it empty if authentication is not required.

Once you click Apply and then Start Streaming, OBS will send an SDP offer to the WHIP endpoint via HTTP POST. The server responds with an SDP answer, and the media starts flowing over WebRTC. That is it. No plugins, no custom signaling servers, no complicated configuration.

Building a WHEP Player in JavaScript

If you are building a website that needs to play a WHEP stream, you can do it with plain JavaScript. Here is a simplified example of what the code looks like.

You create an RTCPeerConnection with the bundle policy set to "max-bundle." You create a WHEP client and call its publish method with your local stream. Then you POST the SDP offer to the WHEP endpoint. The server returns an SDP answer, and you set that as the remote description. After the connection is established, you attach the remote stream to a video element.

There are also ready-made libraries that make this even easier. Several npm packages provide WHIPClient and WHEPClient classes. Other packages provide WHEP plugins for video players. There are also tutorials that walk through building a reusable WHEP player component.

A Simple Workflow

A typical WHIP and WHEP workflow looks like this.

The broadcaster opens OBS and configures a WHIP endpoint. They start streaming. OBS sends an SDP offer to the WHIP endpoint. The media server accepts the offer and starts receiving the WebRTC stream.

A viewer opens a web page. The page creates an RTCPeerConnection and sends an SDP offer to the WHEP endpoint. The media server responds with an SDP answer. The media flows from the server to the viewer's browser over WebRTC. The viewer sees the stream with sub-second latency.

The whole setup is remarkably simple compared to what WebRTC used to require. That is the whole point of WHIP and WHEP.

Security and Authentication

Both WHIP and WHEP support bearer token authentication. The client sends an Authorization header with a bearer token in the HTTP POST request. The server validates the token before accepting the session.

The media itself is encrypted. WebRTC uses DTLS for key exchange and SRTP for media encryption. This means the video and audio streams are protected in transit even if the signaling happens over plain HTTP.

For production deployments, you should always use HTTPS for the WHIP and WHEP endpoints. You should also implement token validation on your server side. Do not rely on the client to enforce authentication. The server should check every session request and reject anything that does not have a valid token.

Which Platforms Support WHIP and WHEP?

Support for WHIP and WHEP is growing quickly. Here is a snapshot of the major platforms as of 2026.

Cloudflare Stream supports both WHIP for ingest and WHEP for playback. Their documentation describes it as sub-second latency live streaming to unlimited concurrent viewers.

Wowza supports WHIP and WHEP. Their WebRTC latency is typically under 500 milliseconds.

Dolby Millicast supports WHIP and WHEP. Their platform is one of the earliest adopters of these protocols.

OvenMediaEngine, MediaMTX, Janus, LiveKit, and Ant Media all support WHIP and WHEP to varying degrees. Some support both protocols fully. Others support WHIP but use proprietary playback methods.

There are also some notable gaps. AWS IVS has WHIP but not WHEP. Mux discontinued its real-time product in January 2024. LiveKit closed WHEP as "not planned" at one point, though their position may have changed.

The lesson here is simple: check vendor support before you commit. The protocols are standardized, but implementation coverage is still uneven.

Should You Migrate from RTMP to WHIP?

If you are currently using RTMP for live streaming ingest, should you switch to WHIP?

The answer depends on your latency requirements.

RTMP is old. It was originally developed for Flash Player, which has been dead for years. It still works, and it is widely supported, but it introduces latency. A typical RTMP ingest combined with HLS delivery gives you five to ten seconds of glass-to-glass latency. Even with low-latency HLS, you are looking at three to seven seconds.

WHIP gets you into the sub-second range. If you are building anything interactive—live auctions, sports betting, remote production, online gaming, or real-time collaboration—WHIP is worth the migration.

The migration itself is not as hard as it sounds. A simple stack migration to WHIP can be a five-week project. The work is a parallel ingest path plus a feature flag, not a full re-platform. The hard part is auditing what else your RTMP origin quietly feeds.

A practical approach is to run WHIP alongside your existing RTMP pipeline. Add a feature flag in your application that lets you switch between them. Test WHIP with a subset of your audience. Once you are confident, make it the default.

Common Mistakes to Avoid

Before we wrap up, let us talk about some mistakes people make when adopting WHIP and WHEP.

Mistake 1: Believing the sub-100 ms marketing. WHIP is a signaling protocol. It does not make WebRTC faster. The latency comes from WebRTC itself, and the realistic floor for CDN-delivered WebRTC is around 200 to 500 milliseconds in good conditions. Plan for 600 milliseconds to 1.3 seconds and you will not be disappointed.

Mistake 2: Assuming every platform supports both protocols. WHIP and WHEP are companions, but they are not always implemented together. Some platforms support WHIP ingest but use proprietary playback. Always verify that the platform you are using supports both sides of the workflow.

Mistake 3: Ignoring WHEP's draft status. WHIP is an RFC. WHEP is still an Internet-Draft. That means WHEP implementations may vary slightly from one vendor to another. Test interoperability before you commit to a vendor.

Mistake 4: Skipping authentication. WHIP and WHEP support bearer tokens for a reason. Without authentication, anyone who knows your endpoint URL can publish or play streams. Always use tokens, and always validate them on the server side.

The Bottom Line

WHIP and WHEP are the missing pieces that make WebRTC practical for broadcast workflows. WHIP gives you a standard way to get a stream into a media server. WHEP gives you a standard way to get that stream out to viewers. Together, they remove the custom signaling code that used to make WebRTC integrations painful.

The latency you can achieve is genuinely impressive. Sub-second is real, though you should plan for 200 to 800 milliseconds in production rather than the sub-100 milliseconds that some marketing pages promise.

If you are building a live video product in 2026, WHIP and WHEP are worth your attention. Start with a small experiment. Set up OBS with a WHIP endpoint. Build a simple WHEP player in a browser. Measure the actual latency on your network. Then decide how far you want to go.

The tools are ready. The standards are here. The only question is what you will build with them.