What is inside a shipping label, and why it matters

A ZPL file is not an image and not a binary format: it is text that anyone can open in Notepad. And what is written in it is this:

^FO50,200^A0N,28,28^FDJoao da Silva^FS
^FO50,240^A0N,28,28^FDRua das Flores 1234^FS
^FO50,280^A0N,28,28^FD01310-100 Sao Paulo SP^FS

Full name, street address with number, postcode. A shipping label usually carries a phone number too, and in many countries a tax or national ID. A batch of five hundred labels is a database of five hundred people, in readable text, in a file of about 1 MB.

None of this is obscure or hidden: it is how the format works, because the printer needs the text in order to print it. What changes is the consequence of forgetting it.

The distinction worth writing down: the data belongs to your customers, not to your company. Under data protection law, whoever handles that file is responsible for it, even when it arrived ready-made from the carrier.

Three slips that turn up every week in support channels and forums:

• Pasting the contents of a real label into a public question, to show the syntax error.
• Emailing or messaging the file to someone else to convert, where it then lives in that inbox forever.
• Using an online converter without reading what it says it does with the file afterwards.

The first is the commonest and the easiest to avoid: replace names, addresses and ID numbers with made-up values before pasting. The syntax error stays perfectly visible, because it lives in the structure of the command, not in the content of ^FD.

The label content passes through the server, because the server is what draws the image. After that it is discarded. Nothing from the file is written to disk, to a database, to object storage, or to a log: not the ZPL, not the rendered image, not the PDF, not the name of the file you uploaded.

That is not a promise of good conduct, it is how the system is built. The service that renders opens no files and writes nothing to disk, and the file is processed in blocks exactly so that no part of it ever needs to be stored somewhere while the job runs.

Account holders get a conversion history. It records five things, none of them drawn from the label content: a row identifier, your account, the label count, the format you chose (PDF or PNG), and the date. It does not record an excerpt of the file, its name, or how many distinct recipients there were. The shape of that row is pinned by an automated test, so that a new column requires a conscious decision instead of slipping in through a change about something else.

This applies to us and to everyone else. Three questions, and all three have an answer you can verify in the service's privacy policy:

• Is the file kept after converting? For how long?
• Does the content appear in logs, error reports or metrics?
• Who inside the company can read what was uploaded?

A service that will not answer those three in writing, not just in marketing, is one you should not feed a real label. Our policy is published and answers all three.

Treat a label file the way you would treat a customer spreadsheet: do not forward it without thinking, do not leave it in a shared folder, delete it when the batch has shipped. It is the same care, and the plain-text format only makes carelessness cheaper for whoever finds the file.