Paste code or load the sample — the result appears below, with the line and severity of each finding.
2Result
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.
