RTSP to WebRTC: How to Watch IP Cameras in Any Browser

Your IP cameras speak RTSP. Your browser does not. This mismatch has been a persistent headache for anyone who wants to view security cameras without installing VLC, an NVR app, or a vendor-specific plugin. The good news: WebRTC is the bridge that makes browser-based camera viewing possible — and in 2026 it works in every major browser with no extensions required.

This guide explains exactly why RTSP fails in browsers, how WebRTC works, what the conversion pipeline looks like, and how to set it up whether you prefer self-hosting or a managed cloud relay.

Why RTSP Fails in Browsers

RTSP (Real Time Streaming Protocol, RFC 2326) was designed in 1998 for media players and dedicated clients — not web browsers. It operates over raw TCP (port 554 by default) or UDP, using a two-channel model: a control channel that sends DESCRIBE, SETUP, and PLAY commands, and separate data channels (via RTP/RTCP) that carry the actual video and audio packets.

Browsers deliberately do not expose raw TCP or UDP socket APIs to JavaScript. The fetch API, XMLHttpRequest, and WebSocket all operate over HTTP/HTTPS. Even the newer WebTransport API, which does use QUIC/UDP, has no facility for speaking the RTSP signaling protocol. There is simply no path for a browser tab to:

• Open a raw TCP connection to port 554
• Send RTSP DESCRIBE/SETUP/PLAY handshakes
• Receive interleaved RTP video packets over that same TCP connection

Older browser plugins like QuickTime, RealPlayer, and ActiveX controls could do this — which is why "just install the plugin" used to be the answer. Those plugins are gone. Chrome dropped NPAPI plugin support in 2015. Modern browsers have no equivalent mechanism.

What WebRTC Is and Why It Works

WebRTC (Web Real-Time Communication) is a collection of browser APIs and network protocols standardized by the W3C and IETF specifically for real-time media in browsers. Unlike RTSP, it was designed from the ground up to work inside the browser security model.

The key components relevant to camera streaming are:

RTCPeerConnection

The core JavaScript API. It handles peer-to-peer (or client-to-server) media transport. The browser uses it to negotiate codecs, send and receive audio/video tracks, and manage network connectivity — all without the page needing raw socket access.

ICE (Interactive Connectivity Establishment)

ICE is the mechanism WebRTC uses to discover a working network path between two endpoints. It tries multiple "candidates" — local network addresses, server-reflexive addresses discovered via STUN, and relay addresses via TURN — and uses the first one that works. For camera-to-browser streaming through a cloud relay, the browser connects to the relay's public IP directly, so ICE succeeds reliably.

DTLS-SRTP

All WebRTC media is encrypted. DTLS (Datagram TLS) is used to key-exchange, and SRTP (Secure RTP) carries the encrypted audio/video packets. The browser enforces this — you cannot receive unencrypted WebRTC media. This is why a conversion server must re-encrypt the stream even if the source RTSP camera sends unencrypted RTP.

The practical result: a browser can receive a live H.264 or H.265 video stream with 100–500 ms end-to-end latency using the standard RTCPeerConnection API, with no plugins, no downloads, and no special permissions beyond normal page load.

The RTSP to WebRTC Conversion Pipeline

Since the browser cannot speak RTSP, a server must bridge the two protocols. The pipeline looks like this:

IP Camera (RTSP/RTP)
      |
      v
 [Conversion Server]
  - Connects to camera via RTSP
  - Receives RTP video (H.264/H.265) + audio (AAC/G.711)
  - Wraps in DTLS-SRTP (WebRTC encryption)
  - Handles ICE negotiation with the browser
      |
      v
 Browser (WebRTC)
  - RTCPeerConnection receives encrypted RTP
  - Decodes H.264/H.265 natively
  - Renders in <video> element

If the camera's codec (H.264 Baseline or Main profile) is already supported by the browser, the server can forward packets without re-encoding — this is called "zero-copy" or "passthrough" mode and is how tools like go2rtc achieve very low latency. If the camera outputs H.265 (HEVC) and the browser doesn't support it natively (which is common on non-Apple platforms), the server must transcode H.265 to H.264 — an expensive CPU operation.

Self-Hosted Options: go2rtc and MediaMTX

go2rtc

go2rtc is a lightweight Go binary that acts as a universal stream router. It can ingest RTSP from a camera and re-publish as WebRTC. You run it on a machine that has network access to the camera.

# go2rtc config (go2rtc.yaml)
streams:
  front_door: rtsp://admin:password@192.168.1.100:554/stream1
  parking_lot: rtsp://admin:password@192.168.1.101:554/h264Preview_01_main

webrtc:
  listen: :8555   # UDP port for ICE candidates

api:
  listen: :1984   # HTTP API / built-in web UI

With this config, go2rtc serves a built-in page at http://your-server:1984 showing WebRTC players. You can also use its API to get SDP offers and build your own player. It supports H.264 passthrough, meaning it does not re-encode the video — latency is typically under 300 ms.

MediaMTX (formerly rtsp-simple-server)

MediaMTX is a more feature-rich media server that supports RTSP, RTMP, HLS, SRT, and WebRTC simultaneously on the same stream. It is also configured via a YAML file:

# mediamtx.yml (relevant section)
paths:
  front_door:
    source: rtsp://admin:password@192.168.1.100:554/stream1
    sourceProtocol: tcp

# WebRTC is enabled by default on port 8889
# Access at: http://your-server:8889/front_door

Both go2rtc and MediaMTX are solid tools. The challenge is infrastructure: you need a machine with a public IP (or port-forwarded access) to serve WebRTC to remote browsers. You also need to handle TLS certificates, since browsers require HTTPS for camera API access and may flag non-HTTPS WebRTC sources.

Cloud Relay: TheRelay

TheRelay is a managed cloud platform purpose-built for this use case. Instead of running your own conversion server, you install a small agent on any machine in the same LAN as your cameras. The agent connects outbound to TheRelay's cloud — no port forwarding, no public IP, no TLS certificate management required.

Once a camera is added, TheRelay automatically provides a WebRTC endpoint accessible at app.therelay.net. The stream is viewable in any browser immediately.

Accessing Your Camera via WebRTC in the Browser

Log in to app.therelay.net, navigate to your camera, and click the WebRTC player. The browser negotiates an RTCPeerConnection directly with TheRelay's WebRTC server — the camera video appears with sub-second latency, no configuration required on your end.

Embedding in Your Own Web Page

TheRelay also provides an embeddable iframe for each stream. Add your camera to any webpage like this:

<!-- TheRelay WebRTC embed -->
<iframe
  src="https://app.therelay.net/embed/webrtc/YOUR_STREAM_ID"
  width="1280"
  height="720"
  frameborder="0"
  allow="autoplay; fullscreen"
  allowfullscreen
></iframe>

Replace YOUR_STREAM_ID with the stream identifier shown in your TheRelay dashboard. The iframe handles all WebRTC signaling internally — no JavaScript setup needed on your page.

Self-Hosted vs Cloud Relay Comparison

Frequently Asked Questions

Can I watch an RTSP stream in Chrome?

Not directly. Chrome does not support RTSP natively. You need a conversion layer — either a self-hosted server like go2rtc or MediaMTX, or a cloud relay like TheRelay — that converts RTSP to WebRTC or HLS before it reaches the browser.

What software converts RTSP to WebRTC?

On the self-hosted side, go2rtc and MediaMTX are the most widely used open-source options. Both are actively maintained, support H.264 passthrough (no re-encoding), and run on Linux, macOS, and Windows. For a fully managed cloud solution, TheRelay handles the conversion automatically with no server required on your end.

Is WebRTC lower latency than RTSP?

On a local network, direct RTSP-to-VLC latency can be very low — often under 500 ms with tuning. Over the internet, RTSP-over-TCP introduces buffering and RTSP clients typically add several seconds of buffer for stability. WebRTC is optimized for real-time transport and achieves 100–500 ms end-to-end latency even over the internet, making it genuinely comparable or superior to RTSP for remote viewing.

Does Safari support WebRTC?

Yes. Safari has supported WebRTC since Safari 11 on macOS High Sierra and iOS 11 (both released in 2017). All major browsers — Chrome, Firefox, Edge, and Safari on both desktop and mobile — support the RTCPeerConnection API natively. No extension or plugin is needed.

Do I need to open firewall ports to use WebRTC with TheRelay?

No. When using TheRelay, the agent on your LAN makes an outbound connection to the cloud infrastructure — similar to how a VPN client works. The browser connects to TheRelay's public WebRTC server, not to your local network. No inbound firewall rules, port forwarding, or DMZ configuration is needed.