Engineering
6 min
The 3 Label Formats Your Warehouse Actually Needs (And Why You Only Have One)
A modern warehouse needs ZPL for Zebra, PDF for customs and archival, PNG for web portals. Most WMS produce one format. Here's why all three matter, the technical differences, and how to close the gap without touching the WMS.
zplflow team
Jul 3, 2026
Every modern warehouse is a polyglot. The printer on the line speaks ZPL. The carrier’s customs portal wants a PDF attachment. The client’s web portal , where end customers track their orders , wants a PNG preview. The compliance archive wants a PDF for long-term retention.
Your WMS produces one format. The rest of the operation improvises.
ZPL is the Zebra Printer Language. It is a stream of ASCII commands (^XA, ^FO, ^FD, ^BC, ^XZ) that the printer interprets into dots. It is fast , a 4x6 thermal label prints in 1.5 seconds. It is precise , barcodes are rendered by the printer’s own engine, not rasterized by a server. It is the format the WMS should be sending to the line, full stop.
Cost in zplflow: 1 token per label for the ZPL output of a pipeline or for a ZPL-to-PDF conversion. PDF-to-ZPL conversion is heavier , 3 tokens at 203 DPI, 4 tokens at 300 DPI , because the source has to be rasterized and re-vectorized into ZPL commands.
PDF is the lingua franca of business documents. Customs declarations, carrier integrations, and compliance archives all want PDF. The advantages are obvious: it is the format every system can read, it preserves the exact visual output, and it embeds fonts and metadata in a single file.
A typical workflow: the WMS generates a ZPL for the printer, but the carrier’s portal needs the same label as a PDF to attach to the commercial invoice. The operations team screenshots the printed label, or worse, asks the WMS to re-generate the same content in PDF , which means maintaining two templates that must stay in sync.
The smarter path is to convert at the point of need. ZPL is the source of truth. PDF is a derived representation generated when the carrier, the customs broker, or the compliance archive asks for it. Cost: 1 token per ZPL-to-PDF conversion.
End customers do not have Zebra printers. They have browsers. When a customer logs into a tracking portal and wants to see what the label looks like , for proof of shipment, for a return, for a re-print at home , the system needs a raster image. PNG is the natural choice: lossless, transparency-capable, universally supported.
A 4x6 label at 203 DPI is 812x1218 pixels. At 300 DPI, it is 1200x1800. The file is small (under 100 KB at 203 DPI for a typical shipping label), renders instantly in any browser. The pattern is the same as PDF: ZPL is the source of truth, PNG is a derived representation for systems that cannot consume ZPL.
If you only have ZPL, every other system has to work around it. The customs portal gets a screenshot. The customer tracking page renders a placeholder. The compliance archive stores a binary blob nobody can search.
If you only have PDF, the printer becomes a software rendering step , slower, more expensive, and dependent on the rendering engine used on the server. The barcode quality drops because it is no longer rendered by the printer’s own engine. If you only have PNG, every system integration has to OCR the image to extract the barcode value, the tracking number, the address.
A modern warehouse needs all three. The mistake is building three separate generation paths inside the WMS.
The fix is to keep ZPL as the canonical output of the WMS and treat PDF and PNG as derived representations generated on demand. The WMS does not change. The integrations do.
For carriers and customs, the ZPL stream is converted to PDF at the moment of handoff:
curl -X POST https://api.zplflow/v1/convert/zpl-to-pdf \
-H "Authorization: Bearer ulb_your_key" \
-H "Idempotency-Key: label-2026-07-03-44781" \
-H "Content-Type: text/plain; charset=utf-8" \
--data-binary $'XlhBeF0ACj4wX0A...the-zpl-stream...^XZ'
# Response: { "request_id": "sync:zpl2pdf:label-2026-07-03-44781", "tokens_charged": 1, "pages": [ { "pdf_base64": "JVBERi..." } ] }
For inbound labels that arrive as PDF , a client sends artwork, a carrier sends a return label, a supplier sends compliance documentation , the conversion runs the other way, at the resolution the printer actually needs:
curl -X POST "https://api.zplflow/v1/convert/pdf-to-zpl?dpi=203&width=101.6&height=152.4&unit=mm&fit=contain" \
-H "Authorization: Bearer ulb_your_key" \
-H "Idempotency-Key: pdfin-2026-07-03-44781" \
-H "Content-Type: application/pdf" \
--data-binary @inbound-label.pdf
# Response: { "request_id": "sync:pdf2zpl:pdfin-2026-07-03-44781", "tokens_charged": 3, "pages": [ { "zpl_base64": "XlhBeF0ACj4wX0A..." } ] }
For the customer-facing portal, the ZPL is rendered to a PNG by a small worker, cached, and served by the existing CDN. The WMS does not produce the PNG. The portal does not know what ZPL is. The conversion is a 50-millisecond step in the rendering pipeline.
| Conversion | Tokens | Notes |
|---|---|---|
| ZPL to PDF | 1 | One label, one token |
| PDF to ZPL (203 DPI) | 3 | Default for thermal printers |
| PDF to ZPL (300 DPI) | 4 | For high-density applications |
| Pipeline (DOM only) | 1 | Up to 16 DOM steps in the base quota |
| Pipeline (with heavy steps) | 1 + 3 per heavy step | Rotate, scale, crop, mirror, margin, image |
A mid-size 3PL producing 100,000 ZPL labels a month, generating 20,000 PDF attachments for carriers, and ingesting 5,000 inbound PDFs from clients, lands at roughly 1 + 20,000 + 5,000×3 = 36,001 tokens. On the Starter plan (€39/month, 60,000 tokens) it is comfortable. On the Growth plan (€149/month, 240,000 tokens) it is invisible.
The point is: you can plan the cost. The cost is on the page before you integrate.
The WMS does what it always did. It produces the canonical ZPL. The integrations, the portals, the carrier handoffs, the compliance archive , each one consumes the format it needs, generated from the same source.
No new templates in the WMS. No second template to maintain. No “this version of the label is for the carrier, that version is for the customer.” One source, three outputs, predictable cost.
zplflow is label infrastructure for 3PLs. ZPL, PDF, PNG , same source, three outputs. Convert PDF to ZPL, transform labels with programmable pipelines, print on any Zebra.
Tags