Can webrtc-internals be improved upon?

Yes. webrtc-internals be improved upon.

Now that we got the answer correct, let's figure out what we really mean by it, shall we?

We'll do it in 3 steps:

1. Understand what's webrtc-internals
2. Explain where we believe it is lacking
3. Introduce our solution (obviously)

What's webrtc-internals anyway

We'll do it quick -

If you are reading this on Chrome or Edge browsers, open a new tab so you don't lose this article and then in your address bar, type "chrome://webrtc-internals" and see what happens. We'll wait.

If you got something like this then great:

If you see something more complex that's probably because you have WebRTC running in one of your other browser tabs. Go check.

Essentially, webrtc-internals monitors the WebRTC activities of the browser and reports that to you, the user. It is a great tool for a developer to be able to understand what's going on under the hood and then troubleshoot, debug and just improve the WebRTC application they are developing.

webrtc-internals gets its information from tracking WebRTC API calls and from using getstats() API itself.

Of all the built-in developer tools available in web browsers, this is likely the most powerful one they have on offer.

👉 Learn more about webrtc-internals

Where is webrtc-internals lacking

If webrtc-internals is so great, then what's the problem? Well, there are a few areas where this tool is lacking:

1. Meant for developers. This tool was built for developers. It means that when a user has a problem, then sending him to webrtc-internals is like asking a car owner to open up the engine and peak inside - just not going to happen
2. Must be opened BEFORE using WebRTC. Bumped into weird behavior with WebRTC? If you open the webrtc-internals tab at this point, you won't see what happened before you opened it - it only starts collecting the statistics and events from that moment in time. You can't really troubleshoot the past without it being opened before. And again, you aren't going to keep this tab open all the time - not even as a developer
3. Got "short memory". That webrtc-internals thing can't store everything. If it would, there wouldn't be enough memory left around for your browser to do anything else. So at some point in time (not too long), it will start "forgetting" the past. It works well for the browser, but not as well for post mortem debugging
4. Garbage collection of closed peer connections. For the same reason above, webrtc-internals will immediately delete everything it knows about a peer connection the moment that peer connection is closed. Which means that you might be too late to debug things simply because the session got closed already
5. Too much information. The number of stats is huge. Finding your way around them isn't easy. And webrtc-internals isn't helping there. We started with this being for developers - which means that as a developer you'll need to really know your way in all the different WebRTC metrics that exist

Introducing: rtcStats

Which is why we ended up launching rtcStats 🎊

rtcStats is built of 3 different components which together gives you the capabilities that webrtc-internals is lacking on its own.

Here's what we're offering:

1. rtcstats. The popular open source client SDK which has been updated and improved quite heavily, bringing it to 2025 and to today's needs. We will be maintaining this client SDK moving forward. You include it in your JS app and it collects what webrtc-internals collects (and more), sending it to a collection server of yours for storage in your backend.
   1. This means you no longer need to users to open webrtc-internals, download the file there and send it to you
   2. You can also do it for all users in all of their sessions. Not only after things are bad and ask them to try again while you "open the logs"
   3. It also supports any session length (at least in theory). It won't lose data the way webrtc-internals does, because it has nothing to preserve - everything is sent to your logging system live (or later - up to you)
2. rtcstats-server. This is another open source project that got revamped. It acts as a simple collection server for the rtcstats client SDK. You can decide to deploy and use it or write your own. We based it on websocket communications and added to it the ability to optionally connect it to rtcstats.com as well. This will make the integration if you need it simpler. Compared to past versions we are starting smaller and less ambitious, just collecting the data for you
3. rtcstats.com. This is our SaaS for displaying everything. It is the missing piece in the rtcstats open source that exists in webrtc-internals. What we did here is make highly opinionated decisions on what's the best approach to looking at this data (and if you know who we are then you know we're quite accustomed to looking at these metrics)

The end result? The most powerful tool you can find for reading WebRTC metrics.

Check us out - there's a free plan we're sure you'll love.