StreamLive Pro

What is WHIP? WebRTC ingest for live streaming

What is WHIP: a standard way to send a live stream over WebRTC with one HTTP request. How it differs from RTMP and SRT, its limits, and where it stands in StreamLive Pro.

Updated November 5, 2026 · 5 min read

WHIP, short for WebRTC-HTTP Ingestion Protocol, is a standard way for an encoder to send a live stream to a server over WebRTC, the technology behind browser video calls. The encoder makes one HTTP request to a WHIP address to set up the session, and the picture and sound then flow over WebRTC. The IETF published WHIP as a Proposed Standard, RFC 9725, in March 2025 (IETF: RFC 9725, checked 5 November 2026). Its companion for watching is WHEP, the egress protocol.

The reason people look at WHIP is delay. WebRTC was built for conversation, so a WHIP stream can reach viewers much faster than a classic RTMP-to-HLS chain. Shorter definitions of related terms are in the Live streaming glossary: the terms you will meet.

WHIP next to RTMP and SRT

The full comparison of the first two is in RTMP vs RTMPS vs SRT: which one to use and when. Delay in general: What is stream latency, and where does the delay come from?.

How a WHIP session starts

The whole point of WHIP is that starting a WebRTC stream becomes as simple as pasting one address. Under the hood, per RFC 9725:

1. The encoder makes an offer. It describes what it wants to send (video and audio codecs, network details) in a session description and sends it to the WHIP URL in a single HTTPS POST request.
2. The server answers. It replies with its own session description and the address of the new session.
3. Media flows. Picture and sound travel over WebRTC, usually over UDP, with encryption built in.
4. The encoder ends the session. When you stop, the encoder sends a DELETE request to the session address.

Before WHIP, every service that took WebRTC in had its own way of doing steps 1 and 2, so an encoder needed custom code for each one. With WHIP, an encoder that supports the standard works with any server that supports it.

What a WHIP setup looks like in an encoder

In recent OBS versions, WHIP is a service type of its own in Settings, Stream: you choose WHIP, paste the URL into Server, and, for Cloudflare's addresses, leave Bearer Token empty. Cloudflare's WebRTC page also lists the codecs it accepts over WHIP: H.264 Constrained Baseline, VP8 and VP9. That is narrower than the H.264 profiles most RTMP setups use, so an encoder profile that works over RTMP may need a change for WHIP. The step-by-step for OBS is in WHIP from OBS to StreamLive Pro: beta status and setup.

Why WHIP is not everywhere yet

• Networks accept RTMP. YouTube, Facebook, Twitch and most others give an RTMP or RTMPS address and key. A WHIP stream would have to be converted before it reaches them.
• Encoders are still adding it. OBS has a WHIP service type in its recent versions; many hardware encoders do not.
• Platforms limit what a WHIP input can do. Cloudflare Stream, for example, says WHIP and WHEP must be used together, and that a WHIP input cannot be restreamed over RTMP or SRT, recorded, or played over HLS (Cloudflare Stream: WebRTC, checked 5 November 2026).

Where WHIP shows up in StreamLive Pro

As a way in, in beta. The encoder card under Stream from software like OBS (RTMP / SRT) has a WHIP tab marked beta, next to RTMP, RTMPS and SRT. We have not tested it with encoders. Because StreamLive Pro receives encoder streams through Cloudflare Stream, whose WHIP inputs are not restreamed over RTMP or SRT, a WHIP push may not reach your networks. For a broadcast that must reach YouTube, Facebook and the rest, use RTMPS or SRT. The details and OBS settings are in WHIP from OBS to StreamLive Pro: beta status and setup.

Not as a destination. Broadcasts leave StreamLive Pro over RTMP, RTMPS or SRT only. A WHIP address saved as a destination is refused with "WHIP and HLS destinations are not supported yet": Destination not supported": WHIP and HLS destinations.

Inside the phone app. The StreamLive Pro phone app sends WHIP, but through a bridge on our servers that turns it into RTMPS before it reaches the broadcast, so it is not affected by the limit above.

In the browser studio. The Browser Studio does not use WHIP to reach us; it sends its own stream to our servers, which pass it on to your networks. You do not set anything.

Should you use WHIP?

Common confusions

• WHIP and WebRTC are not the same word. WebRTC is the technology; WHIP is the agreed way to start sending into a server with it.
• A WHIP URL contains its secret. For WHIP the key is part of the address, so treat the whole URL like a stream key. Cloudflare's WebRTC page says "The broadcast secret is part of this URL, leave "Bearer Token" blank" (Cloudflare Stream: WebRTC, checked 5 November 2026).
• Low delay at ingest does not mean low delay for viewers. Viewers on YouTube or Facebook watch through those networks' players, with their own delay.

Frequently asked questions

What is WHIP in simple words?

A standard way to send a live stream into a server over WebRTC, set up with one HTTP request. It aims for very low delay.

Is WHIP better than RTMP?

For delay, often yes. For reaching social networks, no: most of them take RTMP or RTMPS, and a WHIP stream has to be converted first.

Can StreamLive Pro receive WHIP?

The encoder card has a WHIP tab in beta that we have not tested with encoders. For broadcasts that must reach your networks, use RTMPS or SRT.

Can StreamLive Pro send to a WHIP server?

No. Destinations go out over RTMP, RTMPS or SRT only. Ask the receiving service for an RTMP or SRT address.

What is WHEP?

The matching protocol for watching: a player uses it to pull a WebRTC stream from a server. WHIP is for sending in, WHEP for playing out.

Keep reading