In 2025-2026, the WICG drafted and implemented a new browser restriction called "Local Network Access" which impacts the way plugins like QZ Tray work with the browser.

Although the WICG provided an open forum for plugin authors -- such as QZ Industries, LLC -- little effort has been made by the WICG group to offer graceful suppression, manual triggering or detection in a usable form.

Starting on April 7th, 2026, nearly every Chrome browser will roll out with a pop-up that blocks QZ Tray from connecting.

🗨️ "example.com wants to..."

🖥️ "Access other apps and services on this device"

🖥️ "Access other devices on your local network"

The implementation of Local Network Access (LNA) in Chrome 147 and higher changes how web applications interact with locally installed applications like QZ Tray.

Previously, a website could silently open a WebSocket connection to localhost, however, starting with Chrome 147 (April 2026), modern security policies now treat these connections as a security risk and will prompt the user.

Blocked connections will need to explicitly grant permission for connections to succeed:

• ⚠️ WARNING: Ignoring this pop-up three time is equivalent to clicking "block"!

1. Chrome (and Chromium-based browsers) have been the most aggressive in rolling out LNA restrictions. Starting with Chrome 147, Chrome no longer allows "public" websites to silently connect to "private" addresses (like QZ Tray on localhost).
   • Chrome explainer: https://developer.chrome.com/blog/local-network-access
2. Firefox has a similar permission prompt, but with a checkbox to "remember this decision".
   • Firefox explainer: https://support.mozilla.org/en-US/kb/control-personal-device-local-network-permissions-firefox
3. Safari has not made any official announcement however Apple already imposes Local Network restrictions at the OS-level.

Due to lack of flexibility by the WICG, mitigation is challenging.

• Exceptions can ONLY be made at the domain level
• NO viable mechanism to "whitelist" QZ Tray at install time

For ordinary end-devices, please consider adding an explainer message.

// example only
qz.websocket.connect()
.catch(err => {
    if(err.message.indexOf("Unable to establish connection") !== -1) {
        alert(err.message + "\nEnsure your browser has 'Apps on this device' toggled on.");
    }
});

• 💡 NOTE: There are no LNA-specific changes to qz-tray@2.2.6. Any future API changes as they pertain to LNA can be tracked here: #1382.

Starting with Chrome 147, Chrome blocks WebSocket connections to private network addresses for insecure web pages. This is rare but happens occasionally especially when QZ Tray is running on another machine.

• Any website that does NOT use https://
• Any website that shows "Not Secure" in the address bar
  

• QZ Tray is most commonly run on the same PC using https://, but some environments choose to run QZ Tray in a dedicated (centralized) fashion. Due to certificate complexities, some organizations choose to avoid mixed content restrictions by running the page as HTTP instead of https://.
• Starting with Chrome 147, Chrome blocks these insecure connections. QZ Tray will stop working as a result.

• RECOMMENDED: Well, if your website CAN switch to https://, Chrome 147 and higher has FINALLY relaxes the mixed content restrictions. This means QZ Tray on another machine will work with https://... but requires a code change before this will work... This is a supported change by the Chrome team.

  qz.websocket.connect({ usingSecure: false }); // since 2.0.0

  • 💡 NOTE: To test if this will work for your environment:

    1. Visit https://demo.qz.io
    2. Use the dropdown menu on the Connect 🔽 button ("Connect to QZ Tray running on a Print Server")
    3. Uncheck the ☐ Secure checkbox
    4. Type in the IP address or hostname of the Print Server
    5. Click Connect
       
    6. Contact your app developer and ask them to add support for Chrome 147 and higher (link them directly to this article)

  • ⚠️ WARNING: This will only work in Chrome 147 or higher (or Edge, Brave, or equivalent). Older browsers as well as Firefox and Safari may still require the old, insecure page. See WORKAROUND below if you need to support both.

• WORKAROUND: If your website CANNOT switch to HTTPS, that's OK... You may continue using QZ Tray by adding your website to the chrome://flags/#unsafely-treat-insecure-origin-as-secure exception listing. This is a workaround and may be lost between browser updates.

  • 💡 NOTE:Google also offers an opt-out, but this temporary option will expire in September 2026.

Only for webpages that use iframes, please see this explainer. If your website does not use iframes, this will not help.

Example:

<iframe src="domainB.example" allow="loopback-network domainB.example domainC.example"></iframe>

Although it's technically possible to detect the state of this permission prompt, it's proven a challenging task and the browsers haven't been very sympathetic.

For corporate environments, administrators can bypass these prompts using the LocalNetworkAccessAllowedForUrls (or similar) administrative policy to whitelist your specific domain.

1. Enterprise policy for Chrome: https://chromeenterprise.google/intl/en_ca/policies/local-network-access-allowed-for-urls/
2. Enterprise policy for Firefox: https://mozilla.github.io/policy-templates/#localnetworkaccess (WIP, see here)
3. Safari: Unannounced/unknown. Please reachout to your MDM provider.

Starting with QZ Tray 2.2.6, Company Branded versions can influence these through 'policy' provisions, however due to domain-only values, this feature is limited only to Company Branded builds.

• 💡 NOTE: This feature is available starting with QZ Tray 2.2.6 (April 2026) and all future QZ Tray 2.3.0+ versions.

QZ Industries will continue to monitor the WICG for any mechanism to "whitelist" these connections. Due to initial pushback from the Chromium team, the prospect of any changes in spec is uncertain.

If you have any questions about this please reach out to support@qz.io.

Although this change falls under the WICG umbrella, it's been predominantly spearheaded by one organization: The Google Chrome team. Although I have found interactions with this team to be professional, I feel very strongly that they've NOT been responsible. I've provided use-case for WebSockets after being asked to as an attempt to explain (and for the WICG to understand) the impact this LNA change makes... but the WICG team has provided hardly any useful mitigation at large. Dozens of bug reports, hundreds of messages. By that I mean: Nearly every sane requests to make this rollout developer-friendly has gone dismissed, unanswered, or unresolved and that hurts the very ecosystems that've helped the browser flourish as the gateway to productivity.

Perhaps put best by Chris Edgington WICG/local-network-access/issues/96(comment):

"A remote server in another country that responds to a CORS preflight is trusted without a prompt. A device 10 feet away on the user's own network that responds to CORS preflight + serves a publicly-trusted cert requires a prompt."

QZ Industries, LLC has a philosophy that no matter how big or small a company is, no what a customer's background or reason to use our product -- They deserve to be heard. Here at QZ we're a small, two person company -- yet we read and respond to every single email and we always consider the perspective of our customers and end-users, paid or free. I feel strongly that the WIGC is knowingly dismissing the perspective of their "customers" here and I'm truly sorry that we couldn't do more to ease this transition for ours.

Thanks for trusting in us and our product and for the understanding during this transition.

-Tres Finocchiaro / Owner / Lead Developer