Sign In
Products
ZPL PreviewBarcode GeneratorImage → ZPLZPL cheat sheetLabel DesignerTemplate Gallery
Developers
API QuickstartAPI ReferenceMCP ServerBulk GenerationWebhooksSDKs & ExamplesLimitsOn-Premise
Solutions
Logistics & ShippingE-CommerceERP & WMSManufacturingRetailHealthcare & LaboratoryAll solutions
Tools
ZPL Diagnostics HubZPL DebuggerSize & DPI AnalyzerDPI ConverterBarcode fit calculatorShipping Label AnalyzerFont InspectorOrientation DebuggerCalibration AssistantPrinter Compatibility CheckerBarcode Readability CheckerPrinter Language DetectorThermal Printer Test PackZPL ToolsEPL ToolsTSPL ToolsCPCL ToolsAll ToolsGuidesPricing
Language
EnglishTürkçeDeutsch
HomeSolutionsLogistics and Shipping Labels
Solutions › Logistics & Shipping

Logistics and Shipping Labels

Verify the exact label format your carrier expects on screen, before you send it to the printer.

The problem

Shipping labels have to match the carrier's template exactly: the position of the barcode, the readability of the tracking number, the field where the branch code is printed. These templates arrive as ZPL and most teams can only see them by printing on a thermal printer. A bad label means an unreadable barcode at the distribution centre or a misrouted parcel — and by the time the problem shows up, the shipment is already on its way.

What does Labelixa do?

Verify before printing

Paste the ZPL from your carrier and see the label at its real size. No printer, label roll or physical test required.

Barcode readability

The tracking-number barcode is drawn exactly as produced; a narrow module width or an overflowing field is visible at a glance.

Multi-label and bulk shipments

Get every page of a multi-label ZPL sent in a single request, either separately or as a grid on an A4 page in PDF.

Recipient data never stays on the server

Shipping labels carry recipient names and addresses. The rendering service is stateless: the ZPL you send is never written to disk or logged.

Example label

Logistics and Shipping Labels

This image was produced from the ZPL beside it with the Labelixa engine.

Try your own ZPL code →
ZPL
^XA
^FO30,25^A0N,34,30^FDEXPRESS SHIPPING^FS
^FO30,70^GB540,3,3^FS
^FO30,90^A0N,22,20^FDSHIP TO:^FS
^FO30,120^A0N,26,24^FDJohn Smith^FS
^FO30,152^A0N,20,18^FD114 Main Street, Apt 6^FS
^FO30,178^A0N,20,18^FDBrooklyn / NEW YORK^FS
^FO30,215^A0N,20,18^FDHUB: NY-BROOKLYN-02^FS
^BY3,3,90^FO30,250^BCN,90,Y,N,N^FD7891234567^FS
^FO30,375^A0N,20,18^FDWEIGHT: 3   QTY: 1^FS
^XZ

Commonly used symbologies

SYMBOLOGYCode 128

Tracking number — the carriers' standard choice

SYMBOLOGYQR Code

Mobile scanning in delivery, proof of delivery

SYMBOLOGYData Matrix

High data density in a small area

How to integrate

  1. Paste the ZPL template from your carrier into the preview tool.
  2. Choose the printer resolution (usually 8 dpmm / 203 dpi) and the label size.
  3. Check for field overflow, overlap or an unreadable barcode.
  4. Send the same request from your order-management system via the API; show the PNG to the operator and archive the PDF.

Shipping labels in practice: a closer look

The 4×6 inch and dpi reality

Carriers standardise on 4×6 inch (100×150 mm) labels. At 203 dpi (8 dpmm) that is 812×1218 dots; send the same template unchanged to a 300 dpi printer and everything shrinks to roughly two thirds of its size. Pick the resolution in the preview and compare the two outputs side by side — the drift shows on screen before it hits paper.

Tracking barcodes: quiet zones and the human-readable line

Tracking numbers are Code 128 with almost every carrier. The most common scan failure is another field invading the quiet zone either side of the bars; the second is a too-narrow ^BY module. The human-readable line under the bars is not decoration — when the scanner refuses, manual entry happens from there.

Multi-parcel shipments (1/3, 2/3…)

Parcels of one order are not copies of one label: the piece counter changes and, with most carriers, each piece carries its own tracking number. One template with variable fields plus CSV rows produces the whole set in a single pass — no per-parcel hand editing.

A return label is not a mirror of the outbound one

Returns swap sender and recipient, but the barcode content, the service code and often the template itself change too. Keep the two templates separate and run both through the same preview; 'it worked outbound' is no evidence for the return leg.

Go to the API reference →

Frequently asked questions

Do I have to change my carrier's ZPL template?

No. The template is rendered as-is; the goal is to verify the output the carrier expects without changing it.

Is the recipient data on the label stored by you?

No. The rendering service is stateless: the ZPL you send is never written to disk or logged.

We print thousands of labels a day — does the preview slow us down?

The preview does not have to sit inside the print pipeline. Most teams use it only when a template changes or when debugging; on the API side a single HTTP call per request is enough.