Editor: design label templates

The Editor is a label designer, <zpl-editor>, that you embed in your application. Your users design label templates in it: drag text, barcodes, boxes and images onto the label, set their properties, and mark the parts that change from label to label with variables such as {{order.id}}. The result is a ZPL template that your application stores in its own database. labelviewer stores nothing.

Try it now in the Playground: the real editor inside a mock host app, with every event shown.

The two flows#

Most products use both:

Design, in the browser. Your template page loads a template from your database into <zpl-editor>; when the user presses Save, the editor hands the template to your code and you store it. Embed the editor · Store templates
Print, on your server. When something needs a label (an order ships), your backend takes the stored template and the order's data, asks labelviewer to merge them (POST /v1/merge), and sends the resulting ZPL to the printer. Print from your backend

  Your web app (browser)                 Your backend                     labelviewer (this server)
  ┌───────────────────────┐   load/save   ┌──────────────────┐
  │ <zpl-editor>          │◄─────────────►│ templates API    │◄──► your database (templates)
  │  SDK from /sdk/...    │               │                  │
  └──────────┬────────────┘               │ print job:       │  POST /v1/merge  ┌──────────────────┐
             │ "Test with API" (optional) │ template + order ├─────────────────►│ merge            │
             └────────────────────────────┼──────────────────┼─────────────────►│                  │
                                          │                  │◄──── ZPL ────────┤                  │
                                          │ send ZPL ────────┼──► printer (9100)└──────────────────┘
                                          └──────────────────┘

The variables are the contract between the two flows: the paths a template uses must exist in the data your backend sends at print time, or have a default. Templates & variables explains the syntax and why data can never inject ZPL commands.

What your users get#

A canvas that renders the label pixel-exact as the printer will print it, with rulers, zoom, snapping and undo.
A toolbox (text, barcodes, QR and 2D codes, boxes, lines, circles, images) and a properties pane for the selection.
The ZPL code, kept in sync with the canvas; unknown commands survive every edit.
Sample data and a Variables tab, to preview the label with real-looking values.
A gallery of starter samples (generic shipping carton and pallet templates, not verified for any retailer).

Everything a host can configure (attributes, events, which features are shown, theming) is in the Reference.

Security in one paragraph#

The editor renders in the browser and stores nothing unless you turn on drafts. Its only server calls are the font downloads and, when the user clicks Test with API, POST /v1/merge to the install, without cookies or credentials. Merged data cannot inject ZPL commands, but template authors can write any ZPL, so treat template editing as a privileged action in your app.

Loading the components (URLs, SRI, TypeScript types, CSP) is shared with the Viewer and covered on the SDK page; running the server on Install.