Sooner or later a web application needs to put a label on a
thermal printer, and the first attempt is always the same: open a socket to
the printer from JavaScript. That is not possible, and understanding why
points straight at the patterns that do work.
Why the direct approach cannot work
Raw thermal printing means writing bytes to TCP port 9100. Browsers
deliberately provide no API for arbitrary TCP sockets — page JavaScript can
speak HTTP, WebSocket and WebRTC, all of which require a cooperating server
on the other end. A label printer answering on port 9100 is not such a
server: it speaks no HTTP and performs no handshake. The restriction is a
security boundary, not a missing feature, so no library works around it.
Pattern 1 — the server relays
The browser posts the label to your backend; the backend opens the
socket to the printer and forwards the bytes. This is the default answer
for warehouse and back-office applications, where printers and servers sit
on the same network.
Good: no software on the operator's machine, one place
to log and retry, printer credentials never reach the browser.
Costs: the server must be able to reach the printer —
which rules it out when the printer is on a customer's LAN and your service
is in the cloud.
Pattern 2 — a local helper on the operator's machine
A small program runs next to the browser, listens on localhost, and the
page sends the label to it over HTTP; the helper writes to port 9100. This
is how most vendor "web printing" tools work, and it is the only pattern
that reaches a printer the server cannot see.
Good: works with printers on the user's own network,
survives cloud-hosted applications.
Costs: something has to be installed and kept updated
on every workstation, and a page calling localhost needs the helper to
handle CORS and, on HTTPS pages, mixed-content rules.
Pattern 3 — render, then use the browser's print dialog
Convert the ZPL to an image or PDF, show it, and let the operator print
through the normal driver. No sockets involved.
Good: works everywhere, no install, and it is the
right answer for occasional printing or when the "printer" is really an
office laser.
Costs: the driver rasterises the page, so barcode
edges depend on that rasterisation and page-scaling settings can silently
resize the label. For scannable barcodes at volume, patterns 1 and 2 are
safer — the reasoning is in
PDF vs ZPL for label
printing.
Whatever you choose, look at the label first
Port 9100 has no undo: the printer starts moving media the moment the
job lands. Rendering the job in the browser before sending costs nothing
and catches the structural problems — fields outside the label, a missing
terminator, a barcode with unencodable data. Paste the job into the
ZPL viewer, or call the
rendering API from the same backend that will do
the sending. The operating-system side of actually delivering bytes is
covered in
sending ZPL to a
network printer.
Labelixa DirectPrint
If your labels are rendered or stored in Labelixa, the DirectPrint agent is the local-helper pattern run for you: a small program on a computer in the printer's network that collects print jobs from the API and hands them to the printer — over the network or through a USB printer's print queue. It opens no inbound port. Download and setup: /download
No. Raw thermal printing writes bytes to TCP port 9100, and browsers provide no API for arbitrary TCP sockets — only HTTP, WebSocket and WebRTC, which all need a cooperating server. A printer on port 9100 speaks none of them. It is a security boundary, so no library works around it.
How do web apps print ZPL then?
Three patterns: the backend relays the job to port 9100 (needs network reachability), a small local helper listens on localhost and forwards to the printer (needs an install per workstation), or the label is rendered to an image or PDF and printed through the normal driver (no install, but the driver rasterises the barcode).
