Chrome blocking local file transfers? Check this work or school policy

By Thavasi · Updated 31 October 2026

This guide is for anyone whose browser-to-browser transfers suddenly stopped working in Chrome, and for developers building WebRTC apps who see the same thing. We hit this ourselves while testing WifloShare, and it took a long time to find, because nothing on screen says what's wrong.

Signs this is your problem

• Transfers fail in Chrome with "can't reach each other", but work in Edge or Firefox on the same computer and the same Wi‑Fi.
• It fails in every Chrome window, including Incognito and Guest mode.
• Even two tabs on the same computer can't connect to each other.
• Chrome's menu or settings page says "Managed by your organization".
• It works if you add a relay, but not on the same Wi‑Fi without one.

Why it happens

Chrome has a protection called Local Network Access: websites need permission before they connect to devices on your local network, such as your router, a printer or another computer. Google has been extending it to WebRTC, the technology browser-to-browser transfers use.

Organisations can control this with a Chrome policy called LocalNetworkAccessAllowedForUrls, a list of websites that are allowed. Work and school setups add it, sometimes automatically through Microsoft 365 or OneDrive, so their own sites (for example a SharePoint address) keep working.

In our testing with Chrome 156 on Windows (October 2026), when this policy was present, sites not on the list were silently blocked from making direct WebRTC connections on the local network. There was no permission prompt, and the site's permission even showed as "granted". Edge, which doesn't have the policy, worked normally on the same computer. As soon as we added the site to the list, Chrome connected straight away.

How to check

1. Open Chrome's policy page Type chrome://policy in the address bar and press Enter.
2. Look for Local Network Access policies Look for LocalNetworkAccessAllowedForUrls (or LocalNetworkAccessBlockedForUrls). Its value is the list of allowed sites.
3. Check the list If the site you're using isn't in it, this is very likely the cause.

Fixes for users

1. Use Microsoft Edge or Firefox (quickest)

Open the same site in Edge or Firefox on that computer. The Chrome policy doesn't apply to them.

2. Use a relay

A relay (TURN server) passes the data through the internet instead of your local network, so this policy doesn't block it. In WifloShare you can add your own free Cloudflare relay. It's slower than a direct local connection and uses internet data.

3. Work or school laptop: ask your IT team

If the computer belongs to your workplace or college, don't change its policies yourself. Ask IT to add the site you need, for example https://wifloshare.com, to LocalNetworkAccessAllowedForUrls.

4. Your own Windows computer: add the site yourself

If it's your own computer and the policy came from software you installed (for example signing in to Microsoft 365 with a school account), you can add a site to the list. Open PowerShell as administrator and run:

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Google\Chrome\LocalNetworkAccessAllowedForUrls'

This shows the existing entries, usually numbered 1, 2 and so on. Add the site with the next free number (here, 2):

New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Google\Chrome\LocalNetworkAccessAllowedForUrls' -Name '2' -Value 'https://wifloshare.com' -PropertyType String

Then open chrome://policy, click Reload policies, and reload the site. To undo it later:

Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Google\Chrome\LocalNetworkAccessAllowedForUrls' -Name '2'

If the software that created the policy refreshes it, your entry may disappear. Check chrome://policy again if transfers stop working.

On a Mac, Chrome policies come from configuration profiles (System Settings → Privacy & Security → Profiles). Those are usually managed by your organisation, so use Edge, Firefox or a relay instead.

For developers

If you build WebRTC apps, this failure is easy to mistake for a firewall or NAT problem. What we observed:

• Signalling works: offer, answer and ICE candidates are all exchanged.
• addIceCandidate() resolves successfully for both host (mDNS .local) and srflx candidates.
• getStats() reports zero candidate-pair entries, and iceConnectionState stays checking, then goes to disconnected. A normal firewall block still creates candidate pairs; they just fail.
• navigator.permissions.query({name: 'local-network-access'}) returns granted, so it can't be used to detect the block.
• A TURN relay connects normally.

Check during the attempt, not after it fails. Libraries such as PeerJS close and discard the RTCPeerConnection as soon as ICE fails, so there may be nothing left to inspect afterwards. Sample it every second while connecting:

function watchPaths(pc) {
  const w = { samples: 0, maxPairs: 0 };
  const t = setInterval(async () => {
    if (pc.connectionState === 'connected' || pc.signalingState === 'closed') { clearInterval(t); return; }
    let pairs = 0;
    (await pc.getStats()).forEach(s => { if (s.type === 'candidate-pair') pairs++; });
    if (pc.remoteDescription) { w.samples++; w.maxPairs = Math.max(w.maxPairs, pairs); }
  }, 1000);
  return w;
}
// after the attempt times out:
const blockedByPolicy = w.samples >= 3 && w.maxPairs === 0;   // addresses arrived, but no paths were ever formed

When it returns true, tell the user what's happening and offer a way out: another browser, a TURN fallback, or asking IT to allow your site. Silent failures like this are what make people give up on a tool.

Summary

• Works in Edge but not Chrome, even in Incognito? Check chrome://policy for LocalNetworkAccessAllowedForUrls.
• Quick fix: use Edge or Firefox, or a relay.
• Permanent fix: get the site added to the allowed list, by IT, or yourself on your own computer.