Most teams that print labels end up with one of two
pipelines: generate a PDF and let a printer driver rasterise it, or
generate ZPL and send it to the printer as-is. Both work. They fail
differently, and the failure modes are what should drive the choice.
What actually happens in each pipeline
PDF path: your application composes a page, a driver on
some machine converts that page into printer dots, and the printer burns
them. The label is a picture by the time it reaches the hardware.
ZPL path: your application emits text commands
(^FO, ^FD, ^BC) and the printer
itself draws fonts and barcodes at its native resolution. Nothing
rasterises the page on a computer.
Where each one hurts
PDF pipeline
Native ZPL
Barcode quality
Depends on rasterisation: a barcode
scaled or anti-aliased into dots can lose the crisp bar edges scanners
need
The printer generates the symbol at device resolution — the
usual reason barcode-heavy work moves to ZPL
Job size and speed
A full-page bitmap per label; larger
payloads, slower over slow links
A few hundred bytes of text per
label
Fonts
Embedded in the PDF, so unusual fonts travel with the
job
Limited to printer-resident fonts unless you upload a font to
the printer
Layout fidelity
Exactly what you designed, as long as the
driver behaves
Exactly what you wrote, but coordinates are in dots
and depend on the printer's resolution
Infrastructure
Needs a driver and usually a spooler on a
real machine
Bytes to TCP port 9100; no driver, works from any
server
Variable data at volume
Re-render the whole page per
item
Change the data fields only
Choosing without regret
Scannable barcodes, high volume, server-side generation
→ native ZPL. This is the case the language was designed for, and it
removes the driver from the picture entirely.
Rich graphic design, occasional printing, existing PDF
tooling → PDF. Fighting ZPL to reproduce a designed layout is
usually the wrong trade.
Both is legitimate: keep the operational label in ZPL
and use PDF for the archive copy or the customer-facing document. Rendering
ZPL to PDF is also how you get a printable proof sheet without a printer —
the same job, two outputs.
A caveat worth knowing before you commit
Neither pipeline saves you from the resolution question. A ZPL layout
written in dots for 203 dpi prints at roughly two-thirds size on a 300 dpi
head, and a PDF designed at the wrong physical size is just as wrong on
paper. Declare the real label size and check it before the first
production run.
You can see both outputs of the same file here: paste ZPL into the
ZPL viewer for a rendered image, or use
the API to get PNG or PDF from the same source.
If the printed result differs from what you see, the
troubleshooting triage narrows
it down.
Frequently asked questions
Is ZPL better than PDF for label printing?
For scannable barcodes at volume, usually yes: the printer generates the symbol at its own resolution, jobs are a few hundred bytes, and no driver is involved. PDF is the better choice for rich graphic layouts, occasional printing, or when existing PDF tooling already produces the document.
Why do barcodes scan worse when printed from PDF?
Because the page is rasterised before it reaches the printer. Scaling and anti-aliasing blur the bar edges that scanners rely on. Native ZPL avoids this by letting the printer draw the symbol at device resolution.
