ZPL and EPS export explained

Two of the generator's downloads are not pictures. A ZPL file is a short plain-text script of printer commands: the printer's own barcode engine draws the bars from the digits inside it. An EPS file is PostScript geometry: the rectangles of the barcode you saw on the page, restated in a unit a page-layout program understands. Neither is reached until the input has been validated and the rendered SVG independently decoded — the methodology fixes that order, and the download controls stay withheld until then. The two exporters start from different inputs: ZPL receives the validated payload, check digit included, and never sees the bars; EPS receives the serialised SVG element the decoder just read, and never sees the digits as digits. Every figure below is computed at build time by the code that runs in your browser, on cited reference numbers and on fictional inputs said to be so. It is one of the site's guides; the decoding step it follows is covered in how the verifier decodes what you see.

ZPL: the printer draws the bars

Here is the complete document the EAN-13 generator downloads for the cited reference data 400638133393. Entered as twelve digits, the validator reported "You entered 12 digits — the check digit 1 was computed and appended, making 4006381333931." and the exporter was handed 4006381333931:

^XA
^CI28
^BY3,2,120
^FO50,50
^BEN,120,Y,N
^FD400638133393^FS
^XZ

Top to bottom: the format delimiters open and close it, UTF-8 is declared as the character encoding, ^BY3,2,120 sets the module width and bar height, ^FO50,50 places the origin, ^BEN,120,Y,N selects the EAN-13 command — the Y is the human-readable line, printed by default — and ^FD400638133393^FS carries the data. The module width, bar height and origin values in those lines count printer dots. The generator passes only the symbology and the payload, so every download uses the engine's defaults; the engine accepts height, module-width and origin overrides and clamps them, but the menu does not expose them. Dots-to-millimetre sizing belongs to the ZPL label printing page. The exporter also returns its notes, in this order:

• The ^FD data carries only the data digits — the printer recomputes the check digit and arrives at the same 1 for this EAN-13 that our validator already verified.
• ZPL uses your printer's native barcode engine — the printer draws the bars.
• Preview with a ZPL viewer or run one test label before a production run.

The last 2 appear on every ZPL export and are the format's honest boundary: once the file leaves the browser the printer draws the bars, and nothing on this site can decode what a printer will draw.

Why 12 digits travel for a 13-digit barcode

The field line ^FD400638133393^FS carries the data digits, not the check digit 1, because the EAN-13 command tells the printer to recompute the check digit from the data — the mod-10 arithmetic the check-digit guide walks through. The exporter does not simply trust both ends to agree; it does three things in order: it requires the full payload, check digit included, exactly as the validator produced it; it verifies that check digit independently; only then does it drop the digit and write the field, saying so in the first note above. EAN-8, UPC-A and the ISBN's Bookland EAN-13 get the same treatment; ITF-14's command does not recompute, so its complete number travels. Hand the exporter only the data digits and it refuses:

EAN-13 ZPL export needs the full 13-digit payload including the check digit, exactly as the generator produced it — received "400638133393" (12 characters).

Hand it the fictional corruption 4006381333932 — the reference data with its check digit replaced by 2 — and it refuses again:

EAN-13 check digit mismatch: for data 400638133393 the final digit must be 1, but the payload ends in 2. Re-validate the number before exporting ZPL.

Neither can be reached from the download menu, because the generator passes only the payload the validator accepted; the refusals keep the exporter's contract independent of its caller. Mismatches are reported, never repaired.

One exporter, 7 symbologies

The exporter selects a command for each of the 7 symbologies the validator knows and decides what travels in the field. The table shows its output for the cited vectors and two fictional inputs, the Code 128 and Code 39 rows; computed check digits appear appended.

4 exports carry a first note that is not the recompute note:

• ISBN: The ISBN-to-EAN conversion already happened in the generator — this label encodes the 13-digit Bookland EAN 9780306406157 as a standard EAN-13.
• Code 128: Subset selection is left in automatic mode — the printer picks Code 128 subsets.
• Code 39: Code 39 is printed without a check digit, matching the on-site generator.
• ITF-14: ITF-14 bearer bars are not added by ^B2 — print inside a frame or use label software for bearer bars.

The ISBN row began as the ISBN-10 0-306-40615-2, verified and converted by the validator (the ISBN conversion guide has the arithmetic); the note records that the conversion already happened. The Code 39 row began as the fictional lowercase crate-17; the validator's note, "Code 39 has no lowercase letters — your input was converted to uppercase.", explains the uppercase field. Code 128 subset selection is left to the printer; the code-set guide explains what the validator analyses first. No export format changes what the number is: generating an EAN/UPC barcode does not allocate or license the GTIN inside it — see Do I need a GS1 barcode?

One refusal can be reached from the download menu. The validator accepts the caret and tilde in Code 128 — the fictional LOT^A7 validates and renders — but they are ZPL control characters and cannot travel inside the field. Choose ZPL for that barcode and the generator shows "ZPL export unavailable" followed by:

Code 128 ZPL export cannot carry "^": ^ and ~ are ZPL control characters inside ^FD data. This is a ZPL transport limitation, not a barcode limitation — the symbology itself can encode them, but this export cannot transmit them safely.

The SVG, PNG and PDF downloads of the same barcode are unaffected.

EPS: the bars you saw, in PostScript units

The EPS exporter's vocabulary is deliberately tiny because its input is generated markup, not arbitrary SVG: the svg root with numeric width and height, rect elements for bars, text for the human-readable line; everything else is ignored. One SVG pixel is one PostScript point, so the bounding box is the SVG's width and height, unconverted — the integer bounding box is rounded up to whole points, and the high-resolution bounding box keeps the exact values. And the y-axis flips: SVG measures y downward from the top-left corner, PostScript upward from the bottom-left, so a rectangle at SVG (x, y, w, h) lands at PostScript (x, height − y − h); text is a baseline in both models, so its y flips without the height term. Here is a fictional, generated-style SVG small enough to follow by hand — a white background, two black bars and a centred caption in a 120 × 60 canvas — and the EPS the engine produced from it:

<svg width="120" height="60" xmlns="http://www.w3.org/2000/svg" version="1.1">
<rect x="0" y="0" width="120" height="60" style="fill:#ffffff;"></rect>
<rect x="10" y="5" width="2" height="40" style="fill:#000000;"></rect>
<rect x="14" y="5" width="4" height="40" style="fill:#000000;"></rect>
<text style="font: 12px monospace" text-anchor="middle" x="60" y="56">DEMO-01</text>
</svg>

%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: 0 0 120 60
%%HiResBoundingBox: 0 0 120 60
%%Title: Barcode (EPS export)
%%Creator: barcodesgenerator.net
%%Pages: 1
%%EndComments
%%BeginProlog
% Level 1 interpreters lack rectfill; define an equivalent when missing.
/rectfill where { pop } {
  /rectfill {
    gsave newpath 4 2 roll moveto
    exch dup 0 rlineto exch 0 exch rlineto neg 0 rlineto
    closepath fill grestore
  } def
} ifelse
%%EndProlog
%%Page: 1 1
gsave
0 setgray
10 15 2 40 rectfill
14 15 4 40 rectfill
/Helvetica findfont 12 scalefont setfont
60 4 moveto
(DEMO-01) dup stringwidth pop 2 div neg 0 rmoveto show
grestore
showpage
%%EOF

Follow the first bar: SVG x = 10, y = 5, 2 wide, 40 tall. The flip gives 60 − 5 − 40 = 15, and the engine's line reads 10 15 2 40 rectfill; this page checks at build time that the two agree. The background rectangle is gone: white fills are the page background and EPS graphics are transparent by convention, so the engine skips them and the importing application supplies its own — 2 rectangles painted from an SVG containing 3. The caption is set with /Helvetica findfont 12 scalefont setfont, the printer-resident Helvetica rather than the monospace face the SVG declared; the engine warns on every conversion that renders text — the demo returns 1 warning, "Human-readable text uses the printer's Helvetica; bar geometry is exact." — and the same drawing without its caption converts with 0 warnings. The caption's baseline lands at 60 4 moveto (60 − 56 = 4, no height term), centred with the printer's own string width in (DEMO-01) dup stringwidth pop 2 div neg 0 rmoveto show.

The exporter throws rather than degrade: an SVG whose only rectangles are white background produces "No bars found in SVG markup", a root without numeric width and height "The <svg> root must carry positive numeric width and height attributes", and the generator reports either as "EPS export failed for this barcode"; neither should occur for an SVG the page has just rendered and decoded. EPS, like the PDF exporter the methodology describes, restates the already-decoded SVG's geometry, and as there the file still needs a test scan after printing.

What the tests pin

The test files call both engines directly with the cited vectors. For ZPL the tests pin the default document line for line, the command and the travelling digits per symbology, every refusal above plus Code 39 characters outside its 43-character set and an empty payload, the geometry defaults and clamping, the human-readable flag, the 2 universal notes verbatim and the key phrase of each check-digit, ISBN and bearer-bar note. For EPS they pin the header and trailer, the flip with exact coordinates (fractional heights included, without floating-point noise), black, grey and skipped-white fills, Helvetica substitution, baseline placement, centring, string escaping, the warnings, the refusals and determinism. If any of that changed, the tests would fail — and where this page quotes a line, note or refusal, its build would fail too.

ZPL and EPS export FAQ

Math, not optics: these exports carry verified digits and exact geometry; whether a printed label or a placed EPS scans depends on contrast, size, substrate and preserved quiet zones, which no browser check can certify — test a physical sample with your own scanner before production. Everything runs locally in your browser. See the methodology page for the boundary between the renderer and the verification layer.