Home›Guides›Why does my ZPL label print incorrectly?
Why does my ZPL label print incorrectly?
Published: · Updated:
A ZPL printer almost never reports an error — it prints
something, and the something is wrong. That silence is why label bugs
feel mysterious. In practice, most wrong labels come down to one of five
causes, and each leaves a recognisable fingerprint.
1. The label prints too small or too large
ZPL coordinates are dots, and a dot's physical size depends
on the printer's density. Code written for an 8 dpmm (203 dpi)
printer covers only two-thirds of the space on a 12 dpmm (300 dpi)
one. Nothing is "broken" — the same numbers simply mean fewer millimetres.
Check the printer's density and preview at that same density.
2. Fields run into each other, half the label is gone
The classic cause is a missing ^FS. The field never closes, so
the commands that follow are treated as its continuation, and everything after
the gap collapses into one broken field. The
preview's diagnostics point at the exact line;
on paper you only see the aftermath.
3. Content disappears near the edges
A field positioned beyond the label bounds — an ^FO past
^PW (width) or ^LL (length) — is clipped without any
warning. This typically appears after editing a template for a smaller label
than it was designed for. The fix is not nudging coordinates until it looks
right, but setting ^PW/^LL to the real label size and
checking what overflows.
Two measured details on this cause. First, the number
the printer reports as its print width is not your label: a Zebra GK420d we
measured on 2026-09-04 reported PRINT WIDTH 812 while loaded
with 100 mm (800-dot) stock. A bar placed at ^FO6 with
width 800 was "within 812" and still ended at the label edge on paper,
exactly as the preview had cut it. Second, ^LL does not rescue
you on gap or notch media: the printer uses the label length it
calibrated. That printer had LABEL LENGTH 0410 stored
under a 100 mm label; a field at row 280 printed, one at row 450 never
appeared, and sending ^LL800 changed nothing. Print the
configuration label (^XA^WC^XZ) and compare both stored numbers
with the physical label before touching a single coordinate.
4. The layout drifts from label to label
If ^PW and ^LL are missing entirely, the printer
falls back to whatever it was last configured for — so the same file prints
differently on different machines, or even on the same machine after someone
else's job. Always declare both.
5. Special characters print as garbage
Accented and non-Latin characters (ü, ğ, ß…) need a character-set
declaration. Without it, the printer may interpret the bytes with a legacy code
page. Declare UTF-8 with ^CI28 at the start of the format, and for
characters that cannot travel safely in the data stream, use
^FH hex escapes.
Which guide fixes it: by symptom
The five causes above explain most wrong labels, but the fix lives in
different places. Start from what came out of the printer:
What the printer did
Most likely cause
Open
Everything is there, but shrunk to about two-thirds (or enlarged)
Every one of these is visible before printing: render the file at your
printer's density, at the real label size, and read the diagnostics list. One
screen check replaces a strip of test labels.
Working from a specific symptom instead? The
symptom-to-cause triage page maps
what the printer did to the walkthrough that covers it.
Frequently asked questions
Why does my label print too small or too large?
Density mismatch: positions are in dots, so ZPL written for 203 dpi renders at a different physical size on a 300 dpi printer. Re-target the ZPL for the printer's density.
Why do fields overlap or half the label disappear?
A missing ^FS separator merges fields into each other, and content beyond ^PW/^LL is clipped silently. A validator flags both before any label is wasted.
Why do characters like ö, ü or ç print wrong?
Character encoding: enable UTF-8 with ^CI28 and use a font that has those glyphs. Otherwise the printer substitutes whatever its default code page contains.
My barcode prints but will not scan - is that one of the five causes?
No. A barcode that prints cleanly but stays unread is a symbology problem: module width, quiet zone or darkness. It has its own guide, linked from the symptom table above.
