Local network access restrictions for WebSockets

at a glance

Shipped-versus-recorded-status disagreement, both sides reported rather than resolved: this page records the feature as shipped in Chrome 147 (desktop and Android), while the ChromeStatus record for feature 5197681148428288 still reads status “Proposed” with is_released false and accurate_as_of 2026-03-24 (fetched 2026-10-06). That record's own rollout plan says “Will ship enabled for all users”, which is consistent with the page's enabled-by-default ship if the milestone lands as recorded — so the two are reported together rather than one being chosen.

why it exists

Private network devices (printers, routers, smart home hubs, development servers) often lack authentication and CORS headers, making them easy targets. A malicious public website could silently open a WebSocket to ws://192.168.1.1 and interact with a home router's local admin interface without the user's knowledge. Chrome already gated subresource fetches (HTTP/HTTPS) to local addresses behind LNA checks; Chrome 147 closes the same gap for WebSocket connections.

what changes

WebSocket connection attempts from secure public pages to local/private addresses now require a user permission grant. The browser shows a permission prompt; if the user denies (or no prompt is shown because the site is not secure), the WebSocket connection is blocked.

Affected address ranges

Requirements for the connection to proceed

• The page must be served over HTTPS (secure context).
• For WebSocket connections from <iframe> content, the iframe must include allow="loopback-network".
• The user must grant the Local Network Access permission when prompted.

enterprise policy

Enterprise deployments can bypass the restriction via Chrome policies:

mitigation for developers

If your web application connects via WebSocket to a local server (e.g. a companion native app or dev-mode tool), you have several options:

• Use a local HTTPS server (with a self-signed cert or mkcert): Chrome may allow the connection with permission after the user trusts the cert.
• Serve from localhost: Pages served from http://localhost are themselves treated as a local context and are subject to different rules than public pages.
• Inform users: If the permission prompt is expected, explain it in your onboarding UI — users may dismiss an unexpected prompt and assume something is broken.
• Switch to Isolated Web Apps (IWAs): IWAs have different network access rules and can use allow="loopback-network" in the manifest.

// A public HTTPS page connecting to a companion app on the user's own
// machine. Chrome 147 shows the Local Network Access permission prompt
// before the connection is established; a denied prompt blocks it.
const socket = new WebSocket("ws://127.0.0.1:8787/bridge");

socket.addEventListener("open", () => socket.send("ping"));
socket.addEventListener("error", () => console.warn("Local WebSocket blocked."));

browser support

see also

• New permission prompt for Local Network Access — Chrome for Developers
• WICG Local Network Access specification
• chromestatus — Local network access restrictions for WebSockets (5197681148428288)
• chrome-platform-showcase — live demo