Converting 50, 200 or 500 labels at once without freezing
Large batches are where most converters give up: the tab freezes or memory runs out. How a file of hundreds of labels is processed here, and what to do when it goes over the limit.
Why large batches freeze so many tools
Converting one label means drawing one image. Converting five hundred means drawing five hundred images and then assembling a PDF out of all of them. If all of that happens at once, in one place, memory runs out before the end.
That is why so many converters handle ten labels and die at a hundred: they load the whole file, render everything, hold everything, and only then assemble. The limit is not the size of the text file, which is tiny: it is the size of the images added up. A 10 × 15 cm label at 8 dots per millimetre is nearly a million pixels. Five hundred of them are nearly five hundred million.
How it works here
The file is split into blocks of one hundred labels. Each block goes to the server, comes back as images, and the PDF is assembled in your browser, piece by piece. The server never holds more than a hundred labels at a time, and discards each block the moment it answers.
That split is not only about performance. It is what makes keeping nothing possible: if the whole file had to sit somewhere while the job ran, that somewhere would be a disk, and your label content would start existing outside your machine. Processing one block at a time, no state survives between requests.
The practical consequence: the progress notice counts blocks ("Converting… batch 2 of 5"), so a batch of 500 shows five steps happening rather than a frozen screen with no sign of life.
The limits, and what each one means
| Limit | Value |
|---|---|
| No account | 10 labels per conversion |
| With an account | 500 labels per conversion |
| File size | 2 MB |
| Block sent at a time | 100 labels |
The 2 MB ceiling is almost never what stops anyone: ZPL is text, and a complete shipping label takes about 2 KB. A thousand labels make 2 MB. When that limit does show up, it is usually because the file carries an image embedded with ^GFA repeated on every label, which is the one ZPL element that genuinely weighs something.
Over 500: split the file
A ZPL file is plain text, and each label is an independent block between ^XA and ^XZ:
^XA
^FO50,50^A0N,30,30^FDPedido 1234^FS
^XZCutting between an ^XZ and the next ^XA is always safe: no state crosses label boundaries. What you must not do is cut inside a block, and the effect of that is the worst kind, because the broken label disappears without a word.
In a text editor, search for ^XZ and count. Notepad's find shows a match count, and so does the search panel in VS Code. The number of ^XZ marks is the number of labels.
If the conversion fails partway
A large batch of very large labels is the combination that can still fail, and the limit there is not the count: it is total pixel area. A 10 × 15 cm label at 8 dots per millimetre passes comfortably; the same label at 24 dots per millimetre has nine times the pixels.
If it fails, the first thing to adjust is density, not batch size. Converting the same label at 8 instead of 24 dots per millimetre cuts the area by nine, and in most cases the print stays perfectly legible. The density guide explains how to find out which value your file actually asks for.