Printing real-looking labels while developing is how test packages end up on trucks. Paste ZPL and get it back with a big diagonal VOID - DO NOT MAIL across it (the same way USPS voids a misprint), plus your name. The original fields are untouched, the stamp drawn on top, so no crop of the label looks shippable.
Test labels that look real get mailed. The void tool stamps a large diagonal VOID, DO NOT MAIL across any ZPL label, the way carriers mark sample labels, so a label printed from a staging system or a developer's desk is unmistakable at the dock.
The warning is rasterized and laid corner to corner across the whole label as one graphic field appended after the original commands, so the original ZPL is intact underneath and the stamp cannot be edited out by hand. Where the diagonal crosses a barcode the code may stop scanning, which is the point: a voided label that still scans is a label that can still ship.
Use it on the label your shipping API returns in test mode before it reaches a printer, or in CI as the last step before a virtual printer.
Your data: Your ZPL is processed in memory and discarded when the response is sent; nothing is stored, logged or read by a person. There is no watermark: the void stamp is the output. Details in the privacy policy.
It can. The diagonal runs across the whole label, so wherever it crosses a barcode the code may no longer decode, and the person at the dock sees VOID either way. If you need to scan a test label, scan it before you void it, or keep the unvoided copy in your test fixtures.
Yes. POST /v1/void with the ZPL returns the voided ZPL; wire it into your staging environment so no test label leaves it unmarked.
The tool prints VOID, DO NOT MAIL, which matches what carriers and sorting staff already recognise. The API accepts your own text for other uses (SAMPLE, COPY, TRAINING).
The same engine is behind the API and the guides; every tool here is also an API call.