BarcodesGenerator

Guides

Every barcode this site produces passes through two pieces of software. The renderer turns an accepted payload into bars. The verification layer, implemented independently from published algorithm descriptions, decides what that payload will be and then reads the result back. These guides explain the second piece, one engine at a time: what the validator does to your input (normalise, enforce length and character rules, compute or verify the check digit, report), why (verify-or-compute is explicit, and a mismatch is reported, never repaired), where it stops (math, not optics; symbols, not numbers), and how to read its notes and errors.

No figure in these guides is typed in. Every check digit, conversion, status, count and geometry is computed when the site is built by the code that runs in your browser, on cited reference vectors and on inputs invented for the page; an example the engine cannot compute fails the build. The 7 symbologies share one validator, so the guides cross-link, and the methodology page is the vetted summary each of them expands.

How GTIN check digits are computed

The mod-10 rule behind every EAN-13, EAN-8, UPC-A and ITF-14 number, worked by the engine: weights 3 and 1 anchored at the rightmost data digit, the products summed, the check digit lifting the sum to the next multiple of ten. On the cited reference data 400638133393 the walk-through arrives at 1, making 4006381333931. The guide repeats the arithmetic on an invented number, shows how the digit count selects compute or verify mode, and lets the verifier catch a corrupted digit.

EAN-13 structure explained

How the breakdown engine reads thirteen digits honestly. Only the first three digits, the GS1 prefix, and the last, the check digit, sit at knowable positions. The 9 digits between them are reported as one region, because where the company prefix ends depends on a licence the number does not reveal, and this engine never guesses. On 4006381333931 the prefix is 400, classified standard; the prefix classification never invents a country.

ISBN-10 and ISBN-13 conversion

Two check systems on one number. An ISBN-10 ends in a mod-11 check character — weights 10 through 2, X standing for ten — which the engine verifies first; it then prefixes 978, keeps the nine data digits and recomputes the EAN-13 check digit. The cited example 0-306-40615-2 becomes 9780306406157. The reverse conversion, in the methodology's words, "exists for 978 ISBNs and is explicitly refused for 979", and the guide renders that refusal from the engine's own error.

Code 128 code sets and the Code 39 charset

What the validator checks when there is no check digit. For Code 39 it holds the 43-character set and refuses anything outside it; lowercase is converted, not refused, and disclosed — the fictional part-4402 is encoded as PART-4402 with the note "Code 39 has no lowercase letters — your input was converted to uppercase." For Code 128 the engine analyses which characters force code set A or B and when set C compression applies, as validation and advice; the optimisation inside the symbol is the renderer's.

Bulk GTIN validation modes

How the bulk validator reads a pasted column whose digit count is ambiguous: twelve or thirteen digits may be a complete number or data digits awaiting a check digit. In auto mode the complete-number reading wins — the cited twelve digits 400638133393 are read as a GTIN-12 with the status wrong-check-digit — while in data-only mode every line is data digits and the same row is completed, the completed number in a separate column. The guide defines the 4 statuses and the 500-row cap.

Label-sheet geometry

The arithmetic behind the bulk label PDF. Everything is millimetres on one of 2 page sizes. The 3 Avery presets come from the manufacturer's published templates and are verified arithmetically — margins plus labels plus gaps must reproduce the page exactly, or the test fails. The guide shows where each label lands, how a custom grid is checked against its page and never silently clamped, and what the 300-row cap means. Geometry places symbols; it says nothing about whether they will scan.

ZPL and EPS export explained

What the two text exports carry. A ZPL document needs the full validated payload, check digit included; for EAN and UPC symbologies the engine strips that digit from the field data because the printer recomputes it, and says so — on 4006381333931: "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." EPS translates the generated SVG markup, one SVG pixel to one PostScript point, with the y-axis flipped because PostScript measures from the bottom edge; bar geometry is copied exactly.

How the verifier decodes what you see

The after-rendering half of the verification layer. The interactive generator rasterises the SVG you are looking at and hands the pixels to a decoder independent from the renderer; preview and downloads stay withheld under 2 named reasons, decode-failed and payload-mismatch . The guide follows one number through validation, the payload cross-check and the decode; introduces the verifier page, the same reader for an upload or camera view; and states the deliberate exception — bulk PDF label sheets are validated row by row but not individually decoded.

Editorial guides and the methodology

The engine guides stop where arithmetic stops. The questions beyond that line have their own editorial pages, the ones the site's footer also lists, with the methodology.

Math, not optics: these guides describe checks of digits, character sets and rendered pixels. Whether a printed symbol scans depends on contrast, size, substrate and preserved quiet zones — test with your own scanner before production or print use. Everything runs locally in your browser. The methodology page draws the full boundary between the renderer and the verification layer.