Is there still a browser that does not apply this blocking?

No, not among up-to-date mainstream browsers. Chrome has applied Local Network Access restrictions by default since version 142 (28 October 2025), Microsoft Edge since 143.0.3650.66 (4 December 2025), and Firefox since 153 (21 July 2026), whose release notes state that these restrictions are now enabled by default for all users. Switching from one browser to another is therefore no longer a workaround.

Which Chrome version started blocking localhost?

Chrome 142, released on 28 October 2025. The official release notes state that Chrome 142 restricts the ability to make requests to the user's local network, gated behind a permission prompt. A local network request is any request from a public website to a local IP address or loopback, or from a local website to loopback. An optional flag-based testing phase existed from Chrome 138.

Did the blocking expand after Chrome 142?

Yes. Chrome 142 covered fetch and XHR requests. Chrome 147, released on 7 April 2026, extended the restrictions to WebSocket connections, WebTransport, and service worker navigations through WindowClient.navigate(). Printing utilities that communicated over WebSocket, and had therefore escaped the first wave, have been affected since April 2026.

Which browser blocks local access, and since which version?

Since late 2025, browsers have progressively stopped web pages from reaching a program installed on your own computer. That mechanism is what makes receipt printing fail on online POS software. This page keeps track, version by version and date by date, of the real state of the rollout — with official sources.

📅 Last checked: 2 September 2026, against the vendors' official release notes (links at the bottom of this page). We re-check this page at every major release.

The reference table

Browser	Blocking?	Since version	Date	What is covered
Google Chrome	Yes	142	28 Oct 2025	fetch and XHR requests from a public website to a local IP address or loopback (127.0.0.1, localhost), gated behind a permission prompt.
Google Chrome (extended)	Yes	147	7 Apr 2026	WebSocket, WebTransport and navigations via WindowClient.navigate() added to the version 142 restrictions.
Microsoft Edge	Yes	143.0.3650.66	4 Dec 2025	Same restrictions as Chrome (shared Chromium engine), enabled by default. Enterprise policies can allow specific sites.
Mozilla Firefox	Yes	153	21 Jul 2026	"Local Network Access restrictions are now enabled by default for all users": Firefox requires permission before a site connects to local network devices or to services on your machine.
Brave	Yes	1.54 (ahead of Chromium)	2023	Brave already blocked requests to localhost from public sites through its own permission mechanism, predating Chromium's, which it has been aligning with since.
Opera	Varies	depends on Chromium base	—	Opera follows Chromium with a delay: the blocking arrives when its base is updated. Check version by version — see the method below.
Safari	Differently	—	—	No identical implementation to date, but macOS 15 and later require, at system level, a "local network" permission from applications including browsers: the practical effect can be the same.

The timeline

9 June 2025 — Chrome 138
First trial version: the blocking exists, but only for those who switch it on deliberately through a flag. Nothing changes for the public.
28 October 2025 — Chrome 142
Default switch-on. This is the starting point of the wave of printing failures: online POS software loses access to the station's printing utility, with no error message.
4 December 2025 — Edge 143.0.3650.66
Edge follows. Windows till stations, where Edge is often the default browser, are affected in turn.
7 April 2026 — Chrome 147
The blocking extends to WebSocket and WebTransport. Printing utilities that communicated over WebSocket — and had escaped the first wave — stop working too.
21 July 2026 — Firefox 153
Firefox enables the restrictions by default for everyone. The last way out closes: switching browsers is no longer a workaround.

The fact that changes everything: there is no safe-haven browser left. Until 21 July 2026, moving a till to Firefox worked around the problem — we said so on this very site. That is no longer true. All three major browsers now apply the restriction by default. This was never a Chrome quirk: it is a deep shift in the web platform that every vendor is adopting.

How to check for yourself, on your own station

Your browser's version number is in its "About" menu. But the simplest approach is to measure the effect rather than the version: our free tester tries, live, to reach your own computer from this page and shows you the result in seconds. It is the very same operation your POS software performs when printing.

Why are browsers doing this?

Because a malicious website could silently probe and attack devices on your network: routers, cameras, printers, services listening on your machine. By requiring explicit permission, browsers close that door. The measure is legitimate; so is its side effect on tills that print through a local utility — an effect most POS vendors did not anticipate.

What this means for your till

If your POS software runs in the browser and prints through a small program installed on the station, a browser update alone is enough to break printing, without anything changing on your side. That is why the failure appears "at random", shop by shop: it follows each station's update schedule.

Since the blocking lives in the browser, that is where the path has to be restored. Browser extensions are not subject to this restriction: that is the route our solution takes.

See the fix → Test my station for free

Official sources

Dates for Brave, Opera and Safari rest on concurring secondary sources and are flagged as such in the table; we do not present them at the same level of certainty as those taken from the official release notes above.