How to Disable WebRTC in Firefox, and the Softer Settings That Often Do the Job

To disable WebRTC in Firefox, open about:config, search for media.peerconnection.enabled and switch it to false. That is the whole procedure, and it takes under a minute. The more useful question is whether you need the full switch at all: Firefox ships three narrower preferences that remove the addresses people worry about while leaving video calls usable. This guide covers both routes and how to check what your browser exposes afterwards.

How to disable WebRTC in Firefox, step by step

The steps below follow Mozilla's own support article on the Configuration Editor.

1. Type about:config in the address bar and press Enter.
2. A warning page may appear. Click Accept the Risk and Continue.
3. In the Search preference name box, type media.peerconnection.enabled.
4. Double-click the line, or click its Toggle button. The value changes from true to false and the line turns bold.

There is nothing to save and no restart is listed as a requirement in Mozilla's article. Reload any tab that was already open so that its scripts start again under the new setting.

To undo it, come back to the same line and click Reset. Mozilla's article points out that only modified preferences, the ones in bold, can be reset.

What this switch actually does

Mozilla's WebRTC privacy page describes media.peerconnection.enabled in one line: it "enables/disabled ability to create RTCPeerConnection objects". Its default is true, both on that page and in the Firefox source code as read on 7 October 2026.

RTCPeerConnection is the object a web page uses to set up a direct connection between two browsers. Before it connects, it gathers a list of network addresses called ICE candidates, and the page's JavaScript can read that list. That is the origin of the phrase "WebRTC leak". RFC 8828, the IETF standard on WebRTC IP address handling, names the case that matters most to VPN users: when the VPN and the operating system allow routing over several interfaces, "WebRTC can discover not only the public address for the VPN, but also the ISP public address over which the VPN is running".

With the preference set to false, the comparison table on Mozilla's page is blunt: no local candidates, no external candidates, no relay candidates. Nothing is gathered because the object cannot be created.

The price is equally blunt. Every site that depends on a peer connection stops working in that Firefox profile: calls that run in a tab, screen sharing inside those calls, and web apps that send files or game data straight from one browser to another. Ordinary pages, video streaming and downloads do not rely on it.

The softer settings: keep calls, drop the addresses

If you still take calls in Firefox, the same Mozilla page lists preferences that shape which candidates are gathered instead of forbidding all of them. All of them live in about:config and are changed exactly like the main switch.

Three details from that page are worth reading before choosing.

default_address_only is the one aimed at VPN setups. Mozilla writes that the external address gathered is the one of the default interface and adds, in brackets, "for a VPN, the exit portal of the VPN". In other words, when the tunnel holds the default route, the address behind it is no longer offered. The stated cost: if your router does not support hairpinning, a call between two devices on the same home network is routed through an external TURN server.

no_host deals with the local address. It removes addresses such as 192.168.x.x from the list, the second concern in RFC 8828, which treats them as a fingerprinting surface. Setting both default_address_only and no_host to true lands close to what the RFC calls "Mode 3, default route only".

relay_only is the strict option that keeps calls alive. Every call then passes through a relay server. Mozilla's note is candid about the limit: this "does not hide your external IP address from the TURN server itself", and when the site provides no TURN server, no candidate is produced and the call fails.

One more line in the Firefox source is relevant: media.peerconnection.ice.obfuscate_host_addresses is true by default in Firefox's general preference file (all.js). This is the mechanism that makes a local address show up as a random name ending in .local rather than as a number.

Which setting fits which situation

• You never take calls in Firefox. Use the main switch. It is the only setting with a guaranteed empty result, and you lose nothing you use.
• You use a VPN and take occasional calls in the browser. Set default_address_only and no_host to true. Candidates are still gathered, so calls can keep working, and they follow the route your traffic already takes.
• You need calls and the other party must not learn any of your addresses. relay_only is the documented option, with the caveats above.
• You use Firefox on Android. The preference names are the same. Whether you can change them depends on whether your build opens about:config: type it in the address bar and see. If the page does not open in your version, this method is not available there.

How to check the result

Changing a preference proves nothing by itself. Look at what the browser hands over before and after.

1. Connect your VPN as usual.
2. Open the WebRTC leak test on this site and run it. It works in the browser: it opens a peer connection against a public STUN server and lists every address found in the candidates, flagged as local, public or hidden behind a .local name.
3. Note what appears. A public address that is not your VPN's is the leak to fix.
4. Change the preference, reload the page and run the test again.

With media.peerconnection.enabled set to false, the test can no longer create the connection, so no address can be listed. With the softer settings, expect the VPN's public address and no numeric local address.

What disabling WebRTC does not fix

Turning WebRTC off closes one channel and only one.

It does not hide your address from the sites you visit. Each page still sees where your HTTP request comes from: the VPN server when the tunnel is up, your provider's address when it is not.

It does not touch DNS. A browser can have WebRTC disabled and still send its lookups to your provider's resolver. That is a different test and a different fix, covered in the DNS leak test guide.

It does not handle IPv6. If your VPN only tunnels IPv4, IPv6 traffic can travel outside it whatever the browser settings are. See the guide to VPN IPv6 leak protection.

It is also a per-profile setting. A second Firefox profile, another browser or a desktop app with its own WebRTC stack keeps its own behaviour. For the full list of channels to check in one pass, follow the complete VPN leak test.

In short

media.peerconnection.enabled set to false in about:config disables WebRTC in Firefox entirely, and Reset brings it back. If you still need calls in the browser, media.peerconnection.ice.default_address_only and media.peerconnection.ice.no_host remove the addresses that matter while leaving WebRTC running. In both cases, run a WebRTC test before and after: the setting is only worth what the test shows.