Is the carrier's file really ZPL? How to tell in ten seconds
Not every label file is ZPL. It might be EPL, a PDF with the wrong extension, or a JSON with the ZPL hidden inside. Each one gives itself away in the first line.
The symptom
You upload the file and the answer is "no labels found in the file". The converter is not being fussy: it looked for an ^XA … ^XZ block and found none. The file can be perfectly fine and simply not be ZPL.
This happens more than you would think, because "label file" has become the name of four different things, and the extension is no help: .txt, .prn, .lbl and .zpl get used for all of them.
Open it in a text editor and read the first line
Notepad works, VS Code works, anything that shows the raw content. The first line gives the format away:
| Starts with | What it is |
|---|---|
| ^XA | ZPL. What the converter expects. |
| N, q or Q followed by numbers | EPL, Zebra's earlier language. |
| Already a PDF with the wrong extension. Rename it and open it. | |
| PK and unreadable characters | A ZIP. Unpack it and look inside. |
| { or <?xml | An API response, with the label in one of its fields. |
EPL: the language that looks like ZPL and is not
This is a complete EPL label:
N
A50,50,0,3,1,1,N,"Pedido 1234"
P1No caret anywhere, single-letter commands, text in quotes. It is the language Eltron used before Zebra bought the company, and it is still alive on older printer models.
Many Zebra printers understand both languages and switch by themselves, which is why the file "always worked" on the printer and will not convert here. The converter speaks ZPL, and an EPL file returns exactly the "no labels found" error. We tested it.
There is no automatic conversion between the two: they are different languages with different positioning models. The route is to ask whoever issues the label for ZPL, and it is almost always just a setting in the source system.
ZPL hidden inside a JSON
If the label came from a carrier or marketplace API, the file is often a JSON with the ZPL in one field, sometimes base64-encoded so it survives the trip across the network.
The sign is a file starting with { and holding a field named something like "label", "content" or "data". If that value is readable and starts with ^XA, copying that stretch into a new file is enough. If it is a long block of meaningless letters and digits, it is base64 and has to be decoded first.
It is worth asking whoever built the integration: nearly every API has a format parameter, and requesting the label as plain ZPL removes the step entirely.
When it is ZPL and still fails
If the first line has ^XA and the error persists, two possibilities remain. The first is no ^XZ closing the label, and the guide on why a label never reaches the PDF covers that case and the worse thing it does, which is to vanish in silence when there are other labels in the file.
The second is junk before the first ^XA, which happens when someone copies out of a terminal or an email. Anything outside an ^XA … ^XZ pair is discarded, so this case usually sorts itself out, but it is worth checking that the first ^XA arrived intact.