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 a decade. The costs are structural: the agent installed and updated on every till, certificate management, and $599–2,999/yr licensing for silent printing. The alternative is to move printing off the workstation entirely, onto a device on the network your web app calls directly over HTTP. That device exists: a Proxy Nodes device serves an open HTTP/JSON API on your LAN, and your browser prints with a plain fetch() call.

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 node is a palm-size device that sits next to the printer and serves an open HTTP/JSON API on the LAN. Your web app prints with a plain fetch() call to the node — no agent, no Java runtime, no certificate dance, no websocket-to-localhost trust prompt. On firmware 1.0.24, a node drives a real thermal printer end-to-end today:

• POST /print, GET /status, SSE GET /events, GET/PUT /config, POST /drawer/kick, POST /raw, GET /peers, GET /scans — one JSON contract for the whole peripheral stack
• Live paper, cover, and drawer state over DLE EOT — and when the printer won't answer, the status API reports the state as unknown instead of guessing
• Raw ESC/POS on TCP :9100 with DLE EOT status replies, for software that already prints to network printers
• A drawer-kick pulse measured at 0.15 s, and a barcode scanner on the same node — printer and scanner bind simultaneously behind a powered hub in 1,012 ms, and /scans records a verdict per read with symbology labeled scanner-transmitted (aim) or inferred
• Node-side text wrapping with a measured 48-column default, adjustable per receipt or over PUT /config — tuning a node is a curl, not a reflash
• mDNS discovery (_proxynodes._tcp) and a fetchable API 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, byte-compatible with the node, with fault injection for paper-out, cover-open, and offline — the same 123 conformance specs run identically against the twin or real hardware, so your integration passes CI before a printer exists

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 (our browser printing guide walks through it) — but it's fair to say neither approach makes browsers' security model disappear.

When Proxy Nodes 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. The node is the deployment, once, at the printer.
• 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 "unknown" when the hardware won't answer, instead of a guess.
• You want more than printing on one API. The same node fires a drawer-kick pulse in 0.15 s and serves scanner reads at /scans with a verdict per read. With QZ, the drawer and scanner are separate problems.
• 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 — 123 conformance specs, identical against twin or hardware.

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. Proxy Nodes 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 already run QZ fleet-wide and it works. $599/yr for a system your team knows beats any migration you don't need. Revisit when the tablet question, the agent tickets, or the certificate renewals force it.
• You need ZPL or driver-level features. QZ speaks whatever the OS driver speaks. A node speaks ESC/POS and raw bytes — broad for receipt printing, not a general print server.

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. Proxy Nodes takes the second shape: a node on the LAN, called with fetch().

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 served over HTTPS; our web printing guide covers the working patterns.

Is Proxy Nodes 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 node is a network device with an open HTTP/JSON API plus raw ESC/POS on :9100. Software that already prints to network printers needs no changes; QZ API calls become plain HTTP calls.

What hardware does one node drive today?

A thermal receipt printer (print, cut, live status over DLE EOT), a cash-drawer kick pulse measured at 0.15 s, and a USB barcode scanner — printer and scanner bound simultaneously behind a powered hub in 1,012 ms on real hardware. Ethernet, RS-232, and scale support are in development.

How do I test the integration before buying hardware?

Run the free digital twin. It's byte-compatible with a node — same HTTP API, same raw :9100 — with fault injection for paper-out, cover-open, and offline, and 123 conformance specs that run identically against the twin or a real device.