Published:
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.
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.
| 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 |
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.
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.
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.
ZPL is the language Zebra thermal printers understand. How to read the commands, how a label is put together, and the most common mistakes.
Which barcode symbology should I use?EAN-13, Code 128 or QR? Practical rules for picking a barcode based on your data, your space and the scanner that has to read it.
How to preview a ZPL file without a printerA ZPL file is just text — the label only exists once something draws it. Three practical ways to see a ZPL label before it reaches the printer.