QZ Tray Alternative: No Desktop Agent

QZ Tray solves a real problem — browsers can't print raw ESC/POS — by running a Java agent on the workstation that bridges web pages to local printers, and its LGPL-plus-certificates model has sustained it for years. The costs are the agent itself on every till, certificate management, and $599–2,999/yr licensing for silent printing. The alternative worth weighing is moving printing off the workstation entirely, onto a device on the network your web app can call directly.

What QZ Tray gets right

Respect where it's due. Browsers deliberately can't touch raw printer ports, and window.print() produces letter-sized driver output no receipt printer wants. QZ Tray (qz.io) bridged that gap properly: a local agent exposes a websocket, a signed JavaScript API talks to it, and your web POS prints raw ESC/POS, ZPL, or PDFs to any printer the OS knows. It's open source (LGPL), cross-platform, and has survived a decade of browser security tightening that killed lesser approaches — Zebra's own forums recommend it over Zebra's in-house tool. The business model is honest, too: the software is free; you pay for signing certificates, support, and branding. That ISVs keep paying is proof the pain is real.

What it costs

The recurring dollars are the small part. The structural cost is operational: every workstation that prints needs the agent installed, running, allowed through endpoint security, and kept compatible with Java and browser updates. Each till is a small deployment. And the whole model assumes a workstation exists — an iPad or Android tablet running your web POS can't run a Java agent at all, which is exactly where modern counter hardware is heading.

The alternative: put printing on the network, not the workstation

The QZ architecture exists because the printer hangs off the workstation, so the workstation must be the bridge. Move the printer's brain onto the network and the whole problem dissolves.

A ProxyNode is a small device (ESP32-S3, ~$10 at BOM) next to the printer, serving an open HTTP/JSON API on the LAN. Your web app prints with a plain fetch() call to the node — no agent, no Java, no certificate dance, no websocket-to-localhost trust prompt. What works today, bench-proven on real hardware:

• POST /print, GET /status, GET/PUT /config, /drawer/kick, SSE /events, mDNS discovery
• Live paper, cover, and drawer status over DLE EOT — with known: false when the printer honestly won't say
• Raw ESC/POS on TCP :9100 with status replies for software that already prints to network printers
• Works from any browser on any device — including the iPads and Android tablets that can't run QZ
• Nothing to install or update on workstations; the workstation is just a browser again
• A free digital twin that's byte-compatible with the node, so you can build and CI-test the integration before touching hardware

One honest caveat on browser mechanics: a page served over HTTPS calling a plain-HTTP LAN device runs into mixed-content and Private Network Access rules, the same class of friction QZ's websocket bridge navigates. It's a solvable, documented pattern (and one our browser printing guide walks through) — but it's fair to say neither approach makes browsers' security model disappear.

When ProxyNodes is the better fit

• Your POS runs on tablets. iPads and Android tablets can't host a Java agent; they can make HTTP calls. A network node is the only shape of this solution they can use.
• You're tired of managing agents. No install, no Java runtime, no per-workstation certificate trust, no "the agent didn't start after the Windows update" tickets.
• You want real printer status. QZ hands you the OS driver's view; the node speaks DLE EOT to the printer itself and tells you the truth — including an explicit known: false when the hardware won't answer.
• You want the integration under CI. Point tests at the digital twin, inject paper-out and offline faults, and prove the print path before a printer exists.

When QZ Tray is the right call

• You print to non-receipt hardware from the browser. Laser documents, PDF invoices, label printers via OS drivers — QZ rides the driver stack and handles all of it. ProxyNodes speaks ESC/POS to receipt-class devices; a node can't print your A4 invoice.
• No extra hardware is allowed. Some deployments can't add a device to the network — locked-down corporate sites, or policies that say software-only. QZ is the best software-only answer there is.
• You're shipping this quarter. QZ is proven across thousands of deployments; ProxyNodes pilots are just starting. A deadline decides this one on its own.
• You already run QZ fleet-wide and it works. $599/yr for something battle-tested beats migrating a working system to a prototype. Revisit when the economics or the tablet question forces it.

Related reading: printing from a web app surveys every browser route side by side, WebUSB and Web Serial covers the driverless browser APIs, and the PrintNode comparison covers the cloud-relay route. Developer docs live at /developers.

Frequently asked questions

How much does QZ Tray cost?

The software is free and LGPL-licensed. Silent printing in production practically requires a signing certificate: QZ's Premium support plan is $599/yr and the white-label Company Branded tier is $2,999/yr, per qz.io's licensing page.

Does QZ Tray work on iPads or Android tablets?

No. QZ Tray is a Java desktop agent for Windows, macOS, and Linux workstations. Browser-based POS on tablets needs a different architecture — either a cloud relay or a printing device on the local network the browser can call over HTTP.

Can a web page print to a receipt printer without any agent installed?

Yes, if something on the network speaks HTTP to the printer. A browser can fetch() a LAN print API directly — no agent, no certificate. Mixed-content and private-network rules apply when the page is HTTPS, and our web printing guide covers the working patterns.

Is ProxyNodes a drop-in replacement for the QZ Tray API?

No — it's a different architecture with a different API. QZ bridges the browser to workstation-attached printers through an agent; a ProxyNode is a network device with an open HTTP/JSON API. Replacing QZ means changing your print calls, not swapping a library.

Is ProxyNodes ready for production today?

No. It's prototype-stage: end-to-end validated on real hardware, digital twin and conformance suite public at launch, pilots starting, waitlist open. If you need dependable browser printing this quarter, QZ Tray is the mature choice — that's the honest comparison.