WebRTC Inspector

Live inspection and injection for WebRTC peer connections, tracks, and data channels — DevTools panel UI.

WebRTC Inspector is a free, open-source Chrome DevTools panel for inspecting and testing WebRTC peer connections, data channels, and WebSockets on any web page — live, with no app changes, no SDK integration, and no backend. If you build, test, or support real-time video calling, voice calling, live streaming, or WebRTC-based data apps, this is the tool that shows you what your RTCPeerConnection is actually doing right now, and lets you break it on purpose to prove your reconnect logic actually works. WHY INSTALL THIS Chrome's built-in chrome://webrtc-internals gives you a wall of raw stats and no way to act on them. WebRTC Inspector instead gives you a readable, live DevTools panel plus a full set of fault-injection tools — kill a connection, simulate a signaling outage, corrupt a fake mic feed, intercept a data-channel message — so you can reproduce "the call dropped" or "reconnect never happens" bugs on demand instead of waiting for them to occur in the wild. It's framework- and SDK-agnostic: it patches the standard browser WebRTC/WebSocket APIs directly, so it works identically whether your app is built on plain WebRTC, a commercial SDK, an open-source client, or a custom SFU/MCU integration. WHO THIS IS FOR • WebRTC / real-time engineers debugging peer connections, ICE negotiation, SDP, and data channels during development • QA engineers who need to reliably reproduce degraded-network, packet-loss, and reconnect scenarios instead of relying on flaky real-world conditions • Support and on-call engineers triaging "the call dropped," "video froze," or "audio cut out" reports and needing to correlate a lifecycle event with what was on screen • Teams building or maintaining WHIP/WHEP ingest, SFU/MCU-based conferencing, live streaming, telehealth, IoT device calling, or any product with an embedded video/voice/data channel • Anyone who currently pastes debug code into the console or reads through chrome://webrtc-internals stats dumps by hand WHAT YOU SEE IN THE PANEL • Live RTCPeerConnection state for every connection on the page: connection/ICE state, local and remote tracks, transceivers, data channels, SDP summaries (m-lines, codecs), and local/remote ICE candidate types • WebSocket traffic — signaling, WHIP/WHEP, or any app-level socket — with sent/received counts and recent message previews • Per-connection sparklines for bitrate, RTT, jitter, and packet loss, refreshed every second from live stats • A visual timeline of open/close/error lifecycle events per connection and per channel • A filterable, searchable event log (free text, or type:/conn:/dir: tokens) of the last 20 lifecycle events • One-click copy buttons on SDP, data-channel/WebSocket messages, and log entries — paste straight into a bug report • Automatic dark/light theme sync with DevTools • "Preserve log" across page reloads/navigations, buffered across multiple page loads • Bad-state-first sorting, so a failed or disconnected connection always surfaces to the top of the list • Optional automatic screenshot capture on connection-created, track-added, or reconnect events — visually ties a WebRTC state change to exactly what the user saw • A right-click "Test this stream" overlay on any <video>/<audio> element showing live kind, status, and quality WHAT YOU CAN DO — REAL FAULT INJECTION, NOT MOCKS Every action below calls the real, standard browser WebRTC/WebSocket API on the page you're inspecting — this isn't a simulated preview, it's the same API your app already uses, driven from DevTools instead of your own code: • Inject synthetic audio into a fake microphone track, so the app receives it as genuine mic input • Swap in a generated test-pattern camera feed (configurable size and label text) in place of the real camera • Replace an outgoing audio or video track mid-call • Send a message on an existing data channel as if the app itself sent it, or inject one as if it arrived from the remote peer • Install a data-channel or WebSocket interceptor that rewrites or blocks messages by direction — outgoing, incoming, or both • Kill a connection outright (a real pc.close()) to test cold-reconnect recovery • Simulate a signaling/data-channel network outage for a set duration, to test heartbeat and backoff logic • Restart ICE in place to test renegotiate-without-teardown recovery paths BUILT ON A FRAMEWORK-AGNOSTIC OPEN-SOURCE CORE The panel is powered by an MIT-licensed npm package (@zoharbabin/webrtc-inspector) that patches RTCPeerConnection, RTCDataChannel.send, RTCRtpSender/Receiver, MediaStreamTrack.stop, WebSocket, fetch/XMLHttpRequest (for HTTP-based signaling like WHIP/WHEP), and getUserMedia/getDisplayMedia. Because it patches the standard browser globals rather than any particular SDK, it works on any WebRTC app regardless of which library or vendor it's built on. Beyond the Chrome extension, the same core ships as: • A Playwright test helper — drop it into addInitScript() for scripted, repeatable WebRTC test suites • An MCP (Model Context Protocol) server — lets AI coding agents like Claude Code inspect and fault-inject live WebRTC sessions directly, with a bundled skill covering reconnect testing, quality-regression triage, and signaling-outage recipes • A plain console-paste script for one-off manual inspection with no install at all That means the same debugging vocabulary — kill this connection, simulate this outage, inject this message — works whether a human is doing it from DevTools or an automated test/agent is doing it from code. WHERE THIS FITS: INDUSTRIES AND SCENARIOS WebRTC now sits underneath far more than video calling. WebRTC Inspector is used the same way regardless of what's built on top of it: • Video conferencing and webinar platforms — diagnosing negotiation failures, frozen video, or one-way audio in production support tickets • Live streaming and WHIP/WHEP ingest — inspecting HTTP-based signaling alongside media negotiation in one panel • Telehealth and remote consultation apps — proving call-drop recovery works before it's a patient-facing incident • Online education and virtual classrooms — reproducing "student got disconnected" reports on demand • Customer support co-browsing and screen-share tools — verifying data-channel messaging and screen tracks under simulated packet loss • IoT and robotics remote-control interfaces built on WebRTC data channels — testing command-channel reliability under simulated network loss • Any SFU/MCU-backed conferencing backend — since instrumentation happens at the browser API layer, it's agnostic to which media server sits behind it ADVANCED, OPTIONAL MODULES (for automated/agent-driven testing) These ship in the underlying package and aren't required for interactive DevTools use, but are available for anyone scripting against it: • Scenario compiler — a deterministic keyword/regex DSL (no LLM) that turns a plain-English phrase like "drop packets for 3s then kill the connection" into a sequence of fault-injection calls • Signature matcher — pattern-matches a captured event log against named failure signatures, e.g. a missed-heartbeat reconnect gap or an abrupt close with no recovery • Metrics exporter — pushes per-connection qualityScore, bitrate, RTT, jitter, and loss as Prometheus or OTLP gauges on an interval • Per-site adapters — pluggable hostname-matched labelers/decoders so message previews in the panel can be automatically decoded/labeled for a specific app's protocol QUALITY SCORING AND ANOMALY FLAGS Each connection gets a live 1-5 qualityScore, approximating perceptual audio quality (a simplified ITU-T G.107 E-model on RTT/jitter/loss) and video quality (bits delivered per pixel per frame). It's a diagnostic signal, not a certified MOS/VMAF measurement, but it's enough to spot a regression at a glance. The panel also raises machine-readable flags automatically — ICE stuck in "checking" too long, a data channel opened but never used, a track added with no stats, a bad freeze ratio, an encoder-side quality limitation, or a candidate type flapping between srflx and relay — so you don't have to eyeball raw stats to notice something's wrong. KNOWN LIMITATIONS (so you know exactly what you're getting) • Only sees connections, tracks, and channels created after the patch runs — it must load before the page's own scripts grab references to these APIs, which is how document_start + all_urls loading works here • Per-frame media fault injection (packet-level corruption/delay/duplication via Insertable Streams) is Chromium-only; it no-ops silently elsewhere • Decoded data-channel/WebSocket payloads are size-capped for display but not redacted — treat previews as debug output, not a safe place for secrets • WebTransport, SSE, or a native (non-browser) transport carrying control-plane traffic is invisible to it, since only RTCPeerConnection/RTCDataChannel/WebSocket/fetch/XHR are patched • The qualityScore is an approximate diagnostic signal (simplified E-model for audio, bits-per-pixel-per-frame for video) — useful for spotting regressions at a glance, not a certified MOS/VMAF measurement COMMON QUESTIONS Can I use this on production traffic, or only in development? Both. It's read-only for inspection unless you deliberately trigger one of the fault-injection actions — nothing changes about how the page behaves just from having the panel open. That said, the fault-injection tools call the real APIs (a real pc.close(), a real dropped send), so use them deliberately, the same way you would any other DevTools power tool. Does it slow down the page I'm inspecting? The instrumentation is a thin patch over existing browser API calls plus a once-per-second stats poll for the sparklines — it's built for interactive debugging sessions, not for leaving attached to a production tab indefinitely. Does this require changes to my app? No. It works on any page by patching standard browser APIs before your page's own scripts run. No SDK integration, no code changes, no build step. Does it work with any WebRTC SDK or library? Yes. Because it instruments the browser's native RTCPeerConnection/RTCDataChannel/WebSocket/getUserMedia APIs directly, it's compatible with any WebRTC implementation — vanilla WebRTC, commercial SDKs, open-source clients, and custom SFU/MCU stacks alike. Does it send my data anywhere? No. There is no backend, no telemetry, and no account. Everything runs locally in your browser; the panel simply reads and calls the same APIs your page already uses. Message previews, SDP, and stats are shown only inside your local DevTools panel. Can I use it to test reconnect logic without a flaky network? Yes — this is one of its primary use cases. killConnection tests fresh-session recovery after abrupt death; restartIce tests renegotiate-in-place recovery; simulateNetworkLoss tests heartbeat/backoff detection of a signaling outage — all triggerable on demand instead of waiting for a real network hiccup. Can I automate this instead of clicking through DevTools? Yes — the same capabilities are exposed as an MCP server for AI agents and as a Playwright helper for scripted test suites, both built on the same underlying library as this extension. What permissions does it need and why? It needs the tabs permission (used only for the optional, explicitly user-triggered "Record screenshots" feature) and broad host permissions (needed because it's a generic diagnostic tool with no fixed target site — it has to be ready to instrument whichever page you open next, before that page's own scripts run). See the Privacy tab for full detail. Is it open source? Yes, MIT licensed. Source code, the npm package, the MCP server, and full documentation: https://github.com/zoharbabin/webrtc-inspector