Guides › ZPL prints a blank label

ZPL prints a blank label

Published:

Health report

The printer takes the job, feeds one label — and it is empty. Unlike a shifted or clipped label, a fully blank one usually means the printer executed a format that contained nothing it considered printable. Three structures produce exactly that, and all three are visible in the file.

1. The format never opens — or never closes

Everything a label prints lives between ^XA and ^XZ. Commands arriving outside a format are ignored: a file whose ^XA got lost in copy-paste sends the printer a stream of no-ops. The mirror case blanks differently: without a closing ^XZ the printer keeps waiting for the rest — nothing prints at all until the next job's ^XZ arrives and flushes a mixture of both. Both ends of the sandwich are the first thing to check.

2. A missing ^FS swallows the fields that follow

^FS closes a field. When it is missing, the next commands are treated as a continuation of the same field's data rather than as commands — one lost ^FS early in the format can swallow every field after it, and the "label" that survives is empty or nearly so. The failure grows with template edits: the deleted line took its ^FS with it.

3. Data with no position, position with no data

A ^FD with no preceding ^FO/^FT has nowhere to land; a barcode command with no ^FD has nothing to encode. Both are legal-looking lines that print nothing. Generated files are the usual source — a template variable that emptied out takes the field's content with it and leaves the skeleton behind.

When the file is fine: the path to the printer

If the format opens, closes, and carries positioned data, the blank is upstream of the printhead: a Windows driver not in raw/passthrough mode re-rendering the ZPL as literal text, a wrong printer selected, or media loaded printable-side away from a direct thermal head. Those are integration and loading checks — no ZPL edit changes them.

Sixty seconds before reprinting

All three structural causes are exactly what a syntax check reads from the file: unbalanced ^XA/^XZ, a field-separator chain broken by a missing ^FS, and data fields without a position. Paste, check, fix — then spend a label.

Frequently asked questions

Why does my printer feed a completely blank label for my ZPL job?

Usually a structural cause in the file: commands outside a missing ^XA are ignored, a missing ^XZ leaves the printer waiting, a lost ^FS makes later commands part of a field's data, and a ^FD with no position — or a barcode with no ^FD — prints nothing.

The file looks fine — why is the label still blank?

Then the blank is upstream of the printhead: a driver not in raw/passthrough mode re-rendering ZPL as literal text, the wrong printer selected, or media loaded with the printable side away from a direct thermal head. No ZPL edit changes those.

Can I catch these causes before wasting a label?

Yes — all three structural causes are what a syntax check reads from the file: unbalanced ^XA/^XZ, a field chain broken by a missing ^FS, and data fields without a position. Check first, then print.

Related guides

What is ZPL?

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 printer

A 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.

Try your own ZPL code →