Your ZPL label printed wrong. It's almost always one of these 5 things

labelixa — Wed, 23 Sep 2026 13:34:31 +0000

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. It 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. A linter points 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 reusing a template on a smaller label. The fix
is not nudging coordinates until it looks right: set ^PW/^LL to the
real label size and check what overflows.

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; for characters that cannot travel safely in the data stream,
use ^FH hex escapes.

Find the cause without wasting labels

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. I use Labelixa's viewer
(disclosure: I work on it) — paste the ZPL, pick the density, and the
linter flags the missing ^FS and clipped fields for you. One screen
check replaces a strip of test labels.

Send raw ZPL to a Zebra printer with zero drivers (port 9100)

labelixa — Wed, 23 Sep 2026 13:34:14 +0000

A ZPL file does not need a driver to be printed. Most networked thermal
printers listen on TCP port 9100 ("raw" / "JetDirect" printing) and
treat everything that arrives there as printer commands. Printing a
label is just moving bytes to a socket.

Linux / macOS

nc 192.168.1.50 9100 < label.zpl

That's it. netcat, no CUPS queue, nothing to configure.

Windows

PowerShell opens the same socket without extra tools:

$c = New-Object Net.Sockets.TcpClient('192.168.1.50', 9100)
$b = [IO.File]::ReadAllBytes('label.zpl')
$c.GetStream().Write($b, 0, $b.Length); $c.Close()

From code

Any language with TCP sockets can print. Python:

import socket

with socket.create_connection(("192.168.1.50", 9100), timeout=5) as s:
    with open("label.zpl", "rb") as f:
        s.sendall(f.read())

The catch: 9100 gives you no feedback

There is no response protocol in the simple case. The socket closing
without an error means the printer accepted the bytes — not that
the label printed correctly. Density mismatches and layout bugs are
invisible here. So preview first: paste the ZPL into an
online viewer (disclosure: I
work on Labelixa) and catch the missing ^FS before the printer does.
Port 9100 has no undo; every mistake costs a label and ribbon.

When nothing prints, in order

ping the printer — if that fails it's a network problem, not ZPL.
Is 9100 open? Some printers ship with raw printing disabled or on another port — check the printer's network config page.
Paused or in an error state? A blinking light means the job is queued inside the printer, not lost.
Is the ZPL actually a label? Everything must sit between ^XA and ^XZ — a file without that frame is silently ignored (the #1 "it does nothing" cause).
Prints, but wrongly? Different problem class — that one is about density, ^FS and clipping.

DEV Community: labelixa