What Labelary gets right
The rendering is excellent and the command coverage is the widest available anywhere, which is why it is the yardstick other engines are measured against.
Its free REST API needs no key and became the de facto integration standard — an enormous amount of shipping software has a Labelary URL somewhere in it. On top of that it converts ZPL into EPL, IPL, DPL, SBPL and PCL, ships a real linter with per-command help in the viewer, and publishes a ZPL command reference that has taught most of us the language.
The three limits people actually hit
None of these are flaws. They are the consequences of rendering on somebody else's servers, and they are the reasons people go looking for an alternative.
- The label leaves your machine. Every preview is an upload, and their plans table lists data retention of up to 60 days on the free tier and “never” on the paid ones. For a shipping label that means real customer names and addresses.
- The free API is metered: 3 requests per second and 5,000 per day, with a hard ceiling of 50 labels per request, answered with HTTP 429 and a Retry-After header when you cross it. There are further caps on a single request — 2 MB of virtual printer memory and a 10 MB image buffer.
- Lifting those limits is a subscription: US$90 a month for the Plus plan (6 requests per second, 20,000 a day, 99% SLA) and US$228 for Business (10 per second, 40,000 a day, 99.9%), with on-premise priced on request. Checked on their own plans page, 2026-08-24.
What this does differently
The engine here is a from-scratch ZPL interpreter compiled to run in the browser. That single decision is where every difference below comes from.
- Nothing is uploaded, so there is nothing to retain. Open your Network panel while converting and you will see no request carrying the label.
- No counter and no API key for using the site, because there are no server requests to meter. Rendering costs us nothing per label, so it is not priced per label.
- Whole batches at once: drop a folder or a .zip and every file inside converts in order, archives nested in archives included, into one multi-page PDF or a ZIP of PNGs.
- It runs the other way too. PDFs and images convert into ZPL as dithered ^GF graphics — useful when the carrier only gives you a PDF and the printer only speaks ZPL.
- Unsupported commands produce a warning and the render continues, rather than failing the label.
When Labelary is still the right answer
Three cases, and it would be dishonest to bury them.
- Server-to-server rendering today. Our engine was built to Labelary's URL shape on purpose, but the hosted API is not live yet — until it is, an integration that has to render on a server should keep using theirs.
- Converting ZPL into another printer language. EPL, IPL, DPL, SBPL and PCL output is theirs alone; we render ZPL, we do not translate it.
- Linting and learning. Their per-command help and command reference are genuinely better tools for debugging an unfamiliar command than a warning list is.
The other alternatives worth knowing
If neither of the above fits, these are the ones that come up, and it is worth knowing which is which before you spend an afternoon.
- LabelZoom — developer-focused, converts in both directions, and its PDF-to-ZPL uses layout analysis and OCR to rebuild text and barcodes as real commands rather than as one graphic.
- EditorZPL — like this one, renders client-side and states the code is never sent to a server. Adds a validator, a formatter and a DPI calculator, in six interface languages.
- ZPLPreview — a viewer with shareable preview links and conversions from a long list of formats into ZPL.
- Self-hosted, if the labels must never touch a third party at all: Labelize is an open-source Rust renderer with a CLI and an HTTP mode, and Neodynamic sells a .NET SDK and a Docker web API.