Browser permissions · Tech

The destination decides which Chrome permission to check

A working localhost connection does not establish that a website may reach a printer or router on your LAN.

  1. Two address spacesChrome 145 separates loopback-network for your own computer from local-network for another private-network device.
  2. One grant is not bothCheck the exact destination and the corresponding permission, including any frame policy, before changing server headers.
  3. Permission is only a gateA granted request can still fail because the service is down, the context is unsuitable, or CORS blocks a cross-origin response.

An HTTPS web app can talk to a helper listening at http://127.0.0.1:8765 yet fail when it tries to reach a printer at http://192.168.0.50. The helper and printer may both feel “local” to a user, but Chrome treats their destinations differently. In Chrome 145, Local Network Access (LNA) was split into loopback-network and local-network permissions. A successful request to the helper cannot establish that the other permission was granted.

The fix starts with the request that failed. Inspect its destination in Chrome DevTools, then test the matching gate. Do not add a legacy private-network response header or disable browser protections merely because the two addresses appear to be on the same machine's “network.” The browser's permission, the server's CORS response, and actual device reachability answer different questions.

The two destinations no longer share one permission

A loopback address points back to the user's own device. localhost, 127.0.0.1 and IPv6 ::1 belong to this route. A local-network address points to a separate device on the private network, such as a router at 192.168.0.1 or a printer reached through a .local hostname. The exact name does not settle everything if DNS resolves unexpectedly; the destination address space is the important distinction. MDN's current LNA guide defines those spaces and their permissions.

Two routes in Chrome 145: loopback-network for localhost or 127.0.0.1 on this computer; local-network for 192.168.0.1 or printer.local on another LAN device. One grant does not grant the other.
The copper loop represents a service on the same computer; the teal line represents a different LAN device. Cables are a visual metaphor, not physical network instructions. Sources: Chrome 145 release notes and MDN Local network access, checked 27 September 2026.

Chrome's older local-network-access name remains available as an alias for compatibility. It is not a reliable substitute for reading both new permission states separately: MDN documents a combined alias result that can hide which of the two address spaces matters to the failed request. When debugging a printer, look for local-network; when debugging an on-device helper, look for loopback-network. Browser versions before the split may expose the older name, so record the Chrome version instead of assuming the UI or API is identical everywhere.

This rule applies to a website initiating a request. Typing a printer's address directly into the browser is a different navigation and does not prove that a public web app has permission to call it from a page. Chrome's Chrome 142 notes describe the original prompt for public-to-local or public-to-loopback requests, and for an intranet page calling loopback. The later split refines the permission, not the definition of an accessible device.

Read the first failed gate before changing headers

1. Is the request aimed where you think?

Open DevTools → Network and trigger the exact feature. Record the requesting page's origin, the Request URL, any redirect, the response status or browser error, and whether the request was made in a frame or worker. A redirect from a public hostname to a private IP can change which destination rules are relevant. If nothing reaches the printer, that observation is different from a printer response that the page cannot read. If the address, port or service is wrong, changing site permission will not repair it.

2. Can that document request the matching permission?

LNA permission is limited to secure contexts. An HTTPS page normally qualifies; do not assume an ordinary HTTP public page can simply prompt for access. Chrome can also be constrained by Permissions-Policy. An embedded, cross-origin document may need delegation for local-network or loopback-network; an effective policy denial is not fixed by clicking “allow” on a different page. Check the policy in the frame that actually makes the request. The MDN policy examples show how the two directives and the old alias relate.

Permission prompts protect access to the device; they are not evidence that the device trusts the request. Chrome's LNA announcement explains the security reason: a hostile public page should not silently probe or send requests to private routers and other local services. In managed installations, enterprise policy can affect the result, so an administrator should inspect the browser's applied policy rather than ask users to change global flags.

3. Did transport and the server respond?

If the user granted the right permission but the request still fails, verify that the local service is listening at that host and port, that the device is reachable from this machine, and that its authentication or TLS behavior matches the app's request. A permission cannot start a stopped helper or authenticate to a printer. Chrome documents a conditional mixed-content relaxation for known local destinations after LNA permission is granted; it is not a blanket HTTPS-to-HTTP exception. A public hostname that resolves privately may need an explicit targetAddressSpace annotation, and older browsers may behave differently. Follow the actual network error before applying this remedy.

4. Was the response readable to the page?

A fetch() from a public website to http://192.168.0.50 is also cross-origin. Even if the local-network permission lets the request proceed, the browser's CORS rules can prevent the page from reading the response unless the device or proxy supplies suitable headers for that origin and request. A preflight may fail before the intended request. Conversely, CORS headers on the printer do not grant the user's LNA permission. Diagnose these layers independently; do not apply Access-Control-Allow-Origin: * indiscriminately to an authenticated device.

A reproducible triage for the helper and printer

  • Pin down the pair. Write down the page origin and the failed destination, including scheme, hostname, IP after resolution where observable, and port. Compare 127.0.0.1 with the printer's private IP; do not call both simply “local.”
  • Match the permission. For the on-device helper inspect loopback-network; for the printer or router inspect local-network. Check the requesting frame's effective Permissions Policy and whether the context is secure. On a managed browser, also check applied enterprise policy.
  • Separate a blocked request from a blocked response. A browser permission error or absent network exchange points earlier than a server reply with missing CORS headers. Inspect the Console alongside Network; JavaScript's generic fetch failure alone may not give the cause.
  • Test the service deliberately. Verify device reachability and credentials with an authorized direct diagnostic. Treat direct navigation as a reachability clue, not proof that a page's cross-origin fetch is allowed. Fix the first failed layer and repeat the original feature test.

This order is more useful than a blanket “allow local network” instruction. It also prevents an outdated Private Network Access tutorial from sending you toward Access-Control-Allow-Private-Network as though that header replaced Chrome's current user permission. Chrome says its LNA prompt superseded that earlier preflight-led experiment. Ordinary CORS remains a separate issue for reading cross-origin responses.

The same discipline appears in our Prompt API diagnosis: a surface-level status can conceal different gates. Our fetch timeout example concerns a request that has already begun; a Chrome LNA block may stop a request before that application's timer or parser is the useful place to investigate. Chrome's notification permission is yet another independent grant, not evidence about local network access.

As of 27 September 2026, this is a document-based diagnostic, not a claim that we reproduced every browser and printer combination. LNA integration varies by browser version, request type and deployment policy. The reliable conclusion is narrower: localhost working narrows the problem; it does not clear the separate LAN permission or the downstream server gates.

Questions about Chrome local network access

Does allowing localhost also allow my LAN printer?

No. Chrome 145 has separate loopback-network and local-network permissions. The printer’s private LAN destination needs the latter; localhost working only tells you about the on-device route.

Will adding CORS headers fix a denied local-network permission?

No. LNA controls whether the website may attempt the local request. CORS separately controls whether cross-origin script can read a response. Fix the gate that actually failed.

Why does opening the printer URL directly work while my web app fails?

A top-level address-bar navigation is not the same as a cross-origin request initiated by the app. It can show the device is reachable but does not establish the app’s LNA permission, policy delegation or CORS access.

Is local-network-access the same as the two newer permission names?

It is an older compatibility alias. Chrome 145 documents local-network and loopback-network separately; use the specific permission for the destination when diagnosing a failure.

Browser and web-platform sources

Primary documentation checked 27 September 2026