How to Use chrome://webrtc-internals to Debug WebRTC Calls

What Is chrome://webrtc-internals?

chrome://webrtc-internals is a built-in Chrome diagnostics page that records every active WebRTC session in the browser. It visualizes the RTCPeerConnection API and live statistics - ICE candidates, codecs, packets, jitter, and round-trip time - so you can see exactly why a call connects, degrades, or fails.

Every graph on the page is a value pulled from the WebRTC getStats() API, defined by the W3C Identifiers for WebRTC's Statistics API specification. Chrome samples getStats() on a timer and draws each value as a live chart, which is why the page only shows data while a call is running.

• One section per connection: Each RTCPeerConnection in any open tab appears as its own collapsible block, so a multi-party call shows several sections.
• Event log plus graphs: The top of each section lists signaling and ICE events in order; below it sit the getStats() graphs you expand on demand.
• Live only: Close the tab or end the call and the data disappears, which is why you capture a dump for anything you need to keep.

It sits alongside the other Chrome diagnostics surfaces. If you already use the Chrome Developer Tools Network and Console panels, think of webrtc-internals as the same idea aimed specifically at real-time media. For remote sessions, you can pair it with Chrome remote debugging to inspect a call running on another device.

How to Open chrome://webrtc-internals (Plus Edge and Firefox)

The page captures only the calls that are live while it is open, so the order matters: open the tool first, then start the call.

• Open a new tab and type chrome://webrtc-internals in the address bar, then press Enter.
• Leave that tab open and start or join your WebRTC call in a separate tab.
• Return to the webrtc-internals tab and expand the RTCPeerConnection section that just appeared.
• Expand the stat groups you care about (inbound-rtp, outbound-rtp, candidate-pair) to watch the graphs update in real time.

WebRTC is not Chrome-only, and neither is the tooling. Chrome has supported RTCPeerConnection since version 23, Edge since 79, Firefox since 22, and Safari since 11, which is how WebRTC reaches that 96% browser coverage. Each engine exposes its own internals page:

Firefox's about:webrtc is the most polished alternative. Per the Firefox source documentation, it groups RTP stream, bandwidth, and frame statistics, and the Copy Stats Report button exports the whole session as JSON for a bug ticket. If you regularly compare engines, our guide on Edge vs Chrome and the cross-browser testing hub explain where their behavior diverges.

Reading the Dashboard: Metrics That Actually Matter

The page shows dozens of graphs, but a handful decide whether a call feels good or broken. The W3C statistics specification groups them into objects like inbound-rtp, outbound-rtp, and candidate-pair; these are the values worth watching first.

• packetsLost (packet loss): Rising loss is the top cause of choppy or robotic audio. Under about 1-2% is tolerable for voice; sustained higher loss means the network is dropping media.
• jitter: The variation in packet arrival time, in seconds. Low and flat is healthy; spikes above roughly 30 ms make the jitter buffer stretch and audio stutter.
• currentRoundTripTime (RTT): Network latency on the chosen path. Comfortable calls stay under about 150-200 ms; a high RTT usually means a distant or relayed route.
• bitrate (bytesSent / bytesReceived over time): A falling bitrate during video signals congestion control throttling the stream, often just before the picture blurs or freezes.
• framesPerSecond and frameWidth/Height: Dropping frame rate or shrinking resolution shows the encoder downscaling to protect the connection.
• candidate-pair: Tells you which ICE path won - a local host pair, a server-reflexive (STUN) pair, or a relayed (TURN) pair - which explains a lot about latency.

Read them together, not in isolation. High packet loss with a normal RTT points at a lossy last-mile link, while a high RTT with clean packet counts points at distance or an unnecessary relay. That pairing is what turns webrtc-internals from a wall of charts into a diagnosis.

How to Capture and Read a webrtc-internals Dump

Live graphs vanish the moment the call ends, which is useless when a bug only reproduces on a colleague's machine. A dump solves that by saving the whole session to a file you can open later.

• With chrome://webrtc-internals open during the call, click Create Dump at the top of the page.
• Click Download the PeerConnection updates and stats data to save a JSON file of every getStats() sample and signaling event.
• Attach that JSON to the bug report, or load it into a dump viewer to replay the graphs offline.

The dump is the artifact to ask for whenever someone reports a bad call you cannot reproduce. It contains the full timeline - when ICE connected, when bitrate dropped, when packets started disappearing - so you can pinpoint the failure without being in the room. Firefox users can produce the equivalent with the Copy Stats Report button on about:webrtc.

Debugging Common WebRTC Problems

Most call complaints map to a small set of signatures in webrtc-internals. Use the symptom to know which graph to open, and the graph to know which fix to apply.

Many of these only surface under poor network conditions, so reproduce them on purpose. Our walkthrough on how to test under different network conditions shows how to throttle bandwidth and inject loss so a clean office connection does not hide the bug your users hit on mobile data.

From One Browser to Every Browser: Testing WebRTC at Scale

chrome://webrtc-internals is a single-session, single-machine tool. It tells you why the call on your desk misbehaved, but it cannot tell you whether the same call works on Safari on an old iPhone, a budget Android over a congested network, or Edge on a locked-down corporate laptop. WebRTC bugs love exactly those edges.

That is where the debugging session becomes a test matrix. With TestMu AI you reproduce the call on real hardware instead of one local browser:

• Real devices, not emulators: Run the WebRTC app across the real device cloud of 10,000+ real iOS and Android devices, where camera, microphone, and codec behavior match production.
• Every engine in one place: Validate the same flow on Chrome, Edge, Firefox, and Safari through cross-browser testing instead of hunting for spare machines.
• Signaling included: WebRTC still needs a signaling channel to set up a call, so confirm your transport holds up; the WebSocket browser support guide covers the layer that carries those offers and answers.
• Voice agents that ride on WebRTC: If the call carries a voice bot or phone agent, healthy transport is only half the test. TestMu AI's Agent Testing platform replays the agent across 200+ voices and 20+ noisy, poor-connection environments to confirm it still recognizes intent when packet loss and jitter climb.

The workflow is the same loop every time: capture a dump locally, identify the failing metric, reproduce it on the device and browser where users see it, ship the fix, and re-run to confirm packet loss and RTT are back in range.

Automating WebRTC Checks With getStats()

You will not open webrtc-internals by hand before every release. The same metrics it charts come straight from getStats(), so you can assert on them inside an automated test. Running a loopback RTCPeerConnection on Chrome 148 and calling getStats() returns exactly the objects the page draws - here is a real capture from that run:

// Real getStats() output captured from a live RTCPeerConnection (Chrome 148)
{
  candidatePair: { state: "succeeded", currentRoundTripTime: 0.001, bytesSent: 2535, bytesReceived: 1724 },
  transport:     { dtlsState: "connected", packetsSent: 33, packetsReceived: 21 },
  dataChannel:   { state: "open", messagesSent: 25, bytesSent: 165 }
}

Wrap that read in a Selenium test on the TestMu AI cloud grid, and a quality regression fails the build instead of a support ticket. The capabilities below route the test to a real cloud browser; see the desired capabilities documentation for the full option list and the Selenium tutorial for setup.

const { Builder } = require("selenium-webdriver");

const capabilities = {
  browserName: "Chrome",
  browserVersion: "latest",
  "LT:Options": {
    platform: "Windows 11",
    build: "WebRTC Quality Checks",
    name: "Assert RTT and packet loss",
    user: process.env.LT_USERNAME,
    accessKey: process.env.LT_ACCESS_KEY,
  },
};

const driver = new Builder()
  .usingServer("https://hub.lambdatest.com/wd/hub")
  .withCapabilities(capabilities)
  .build();

await driver.get("https://www.testmuai.com/selenium-playground/");

// Pull live WebRTC stats from the page's RTCPeerConnection
const stats = await driver.executeAsyncScript(async (done) => {
  const report = await window.pc.getStats();
  let rtt = null, lost = null;
  report.forEach((s) => {
    if (s.type === "candidate-pair" && s.nominated) rtt = s.currentRoundTripTime;
    if (s.type === "inbound-rtp") lost = s.packetsLost;
  });
  done({ rtt, lost });
});

if (stats.rtt > 0.2 || stats.lost > 50) {
  throw new Error("WebRTC quality regression: " + JSON.stringify(stats));
}

await driver.quit();

Now the metrics you used to eyeball in webrtc-internals become a pass/fail gate. Point the same assertion at different devices and networks to catch the call quality regressions that only appear off your own machine.

Conclusion

Start with one concrete habit: on your next test call, open chrome://webrtc-internals first, then watch currentRoundTripTime and packetsLost while you talk. Within a minute you will know whether a problem is latency, loss, or a bad ICE path - and you will have a dump to prove it.

Then close the loop where users actually are. Reproduce the call across browsers and devices on TestMu AI's real device cloud, automate the getStats() assertion with the getting started with automation guide, and make WebRTC quality a build gate instead of a guess. The browser tool finds the bug; the cloud confirms the fix holds everywhere.