How the verifier decodes what you see

Every barcode the interactive generator shows you has been read back. It does not stop at drawing bars from a validated number: it rasterises the drawing you are looking at, hands the pixels to a decoder independent from the renderer, and compares what came back with what the validator approved. If the two disagree, or nothing can be read, the preview and the download controls stay withheld. This guide — one of the guides to this site's engines, every figure computed at build time — follows one number through that pipeline so that the notes, verdicts and refusals on a tool page, and on the Barcode Verifier & Scanner, read as what they are: the verification layer made visible, inside the boundaries the methodology page draws.

Two pieces of software, two jobs

Rendering — turning an accepted payload into a symbol's module pattern — is the work of JsBarcode, an MIT-licensed open-source library, pinned to an exact version and used unmodified; a test fails if the pin drifts. Everything around it is this site's own, implemented independently from published algorithm descriptions: one part runs before the renderer and decides what the symbol will carry, the other runs after it and reads the result back. Neither trusts the renderer.

Stage one: the validator decides what the symbol will carry

The validator does four things, in order. It normalises the input — spaces and hyphens stripped from digit strings, an ISBN's hyphens and trailing x tidied, Code 39 letters uppercased. It enforces the symbology's length and character rules. It computes or verifies the check digit with its own arithmetic: data digits in, check digit computed and appended; complete number in, final digit verified. And it reports what it did in notes, so nothing is applied invisibly. A mismatch stops the flow before any bars are requested.

Take the data digits of a cited reference vector, 400638133393, from a published EAN-13 check-digit walkthrough. Entered as twelve digits on the EAN-13 generator, the engine runs in its computed mode and the note reads:

You entered 12 digits — the check digit 1 was computed and appended, making 4006381333931.

Enter the resulting thirteen digits, 4006381333931, and the engine runs in its verified mode instead:

You entered all 13 digits — the check digit 1 was verified against the first 12 and is correct.

Both notes come from the validator at build time; the check digit 1 is its result, not a typed figure.

Now corrupt the complete number with a fictional typo: position 5, the digit 3, entered as 4, giving 4006481333931. The verdict is an error, not a repaired barcode:

Check digit mismatch: for 400648133393 the final digit must be 0, but you entered 1. Fix the number, or enter only the first 12 digits to have the check digit computed.

Underneath, the verification routine reports the data digits 400648133393, the digit they require, 0, and the digit supplied, 1.

The typo was in a data digit, yet the check digit is the one that no longer fits — which is why this engine never substitutes the digit that would make the number valid: a quietly corrected check digit turns a detectable error into a valid wrong number. The arithmetic is walked through in how GTIN check digits are computed.

Stage two: the payload is cross-checked before it is drawn

The accepted payload is checked once more: its check digit is re-derived with the independent arithmetic and compared with the digit the validator recorded. On 4006381333931 that cross-check passes. A failure here would be a bug, not a typo: the barcode would not be shown and the error would ask you to report it. Code 128 and Code 39 carry no visible check digit, so this stage passes trivially for them; their integrity comes from character-set validation and, for Code 128, the mod-103 symbol check built into the symbology itself. See the code-set and charset guide.

Stage three: the pixels are read back

Only now is the renderer called, and its output is not taken on trust: the generator rasterises the actual SVG shown on the page and asks ZXing, a decoding engine independent from the renderer, to read those pixels. The result has two failure reasons, named in the engine as decode-failed and payload-mismatch: the decoder could not read the rendered bars, or it read a text that is not the validated payload, in which case the message quotes what it read. Either way the preview and the download controls remain withheld. On success the engine returns the decoded text and the format name.

The downloads are covered separately. PNG export is rendered to its own canvas and decoded again before the file is released. The single-barcode PDF exporter translates the independently decoded SVG's rectangles and caption into native PDF vector geometry rather than embedding a screenshot. ZPL and EPS are text translations of the validated payload and the generated SVG markup; ZPL and EPS export explained says what each carries.

What "the same payload" means

The comparison is exact, with two disclosed equivalences: a UPC-A reader may report twelve digits or the equivalent zero-prefixed thirteen, and a multi-format reader may report an EAN-13 that begins with 0 as the twelve-digit UPC-A with the zero stripped. Both spellings are the same printed symbol, so the engine accepts both and nothing else. The table hands the engine's comparison, at build time, each payload itself or as a fictional misreading, the two equivalences, and two inputs exactly as typed:

Symbology	Validated payload	Reading handed to the comparison	Engine's verdict
EAN-13	`4006381333931`	`4006381333931`	Accepted — same symbol
EAN-13	`4006381333931`	`4006481333931`	Withheld — payload mismatch
UPC-A	`036000291452`	`0036000291452`	Accepted — same symbol
EAN-13	`0036000291452`	`036000291452`	Accepted — same symbol
ISBN	`9780306406157`	`0306406152`	Withheld — payload mismatch
Code 39	`PART-4402`	`part-4402`	Withheld — payload mismatch

Two of the withheld rows are the common surprises. An ISBN barcode carries the ISBN-13: the cited ISBN-10 0-306-40615-2 is verified, converted to 9780306406157 and handed to the renderer in its EAN13 format, so a decoder reports the thirteen digits (the conversion guide shows the arithmetic). Code 39 has no lowercase letters: the fictional input part-4402 becomes PART-4402 and the note says so — "Code 39 has no lowercase letters — your input was converted to uppercase." Decoded values are compared with the payload the notes report, never with your keystrokes.

The verifier page: the same reader, your image

The Barcode Verifier & Scanner exposes the same independent-reader idea for an uploaded image or a camera view, built around the 7 symbologies this site generates — Code 128, EAN-13, EAN-8, UPC-A, ISBN, Code 39 and ITF-14 — with ISBN barcodes decoding as EAN-13 because that is what their bars carry. A successful decode proves that the image contains a readable one-dimensional symbol, and reports the characters its bars encode — compare them with the payload the notes reported. Images and camera frames stay on your device.

The deliberate exception: bulk label sheets

Bulk PDF label sheets are the one product here that is not read back, and the methodology says so. Each pasted row — up to 300 lines — receives structural and check-digit validation before rendering, but the rows of the assembled PDF are not individually decoded. A sheet is validated, not independently read, so scan a printed sample; its grid arithmetic is in label-sheet geometry.

Where the check stops: math, not optics

No browser check can certify ink, substrate, scaling, contrast or quiet zones after printing, so a physical production sample must still be scanned. Where this site quotes physical figures at all — EAN-13 quiet zones of 11 and 7 module widths, UPC-A's 9, ITF-14's 10, the 0.264–0.660 mm consumer X-dimension range — they come from GS1 member-organisation size guides such as GS1 Sweden's; otherwise the guidance stays qualitative, with no invented DPI table. The second limit is as firm: generating an EAN or UPC barcode does not allocate or license the GTIN inside it, and rendering an ISBN barcode does not register an ISBN. Whether your product needs a licensed number is answered in Do I need a GS1 barcode?

Reading the notes, the verdicts and the refusals

A note beginning "You entered…" names the mode that ran: computed, the check digit was appended for you; verified, you supplied it and it checks out. A conversion or uppercase note discloses a normalisation.
A "Check digit mismatch" error names the data digits, the digit they require and the digit you supplied, then offers the data-only route — a refusal, never a repair.
A payload-mismatch or decode-failed refusal comes from the independent decoder: the first quotes what it read instead of the validated payload; the second means it could not read the bars and suggests a shorter value or a report through the contact page.

Common misreadings

"Verified" means registered. It means structurally valid and read back; licensing is not checked.
A decoded preview will scan when printed. That is optics, not math — test the printed result with your own scanner.
A mismatch means the last digit is wrong. The number as a whole is inconsistent — above, a data-digit typo surfaced as a check-digit mismatch.
A label sheet is verified like a single barcode. Its rows are validated; the assembled PDF is not decoded.

Verification FAQ

Why is the preview withheld when my number passed validation?

Because validation is only the first check. The drawing you see is also read by a decoder independent from the renderer, and the preview and downloads are withheld for two reasons: decode-failed, when it cannot read the rendered bars, and payload-mismatch, when it reads a different text from the validated payload. The message says which.

What is the difference between the payload cross-check and the independent decode?

The cross-check re-derives the check digit of the accepted payload with the independent arithmetic and compares it with the digit the validator recorded; it inspects no bars. The independent decode reads the rendered pixels. Both must pass before the preview and downloads are released.

What does the verifier page prove about a downloaded file?

It proves the image contains a readable one-dimensional symbol and reports the characters its bars carry; compare that value with the payload the generator’s notes reported. It does not prove a future print run will scan, and says nothing about whether a number is licensed.

Why does the decoded value differ from what I typed?

Because the symbol carries the validated payload, not your keystrokes, and the notes disclose every change: the ISBN-10 0-306-40615-2 is converted before rendering, so the bars carry 9780306406157; lowercase Code 39 input is uppercased, so part-4402 decodes as PART-4402; a UPC-A may be reported with a leading zero, which the engine accepts as the same symbol. Anything else is a genuine mismatch and is withheld.

Does a successful on-screen decode mean the barcode will scan after printing?

No. The decode checks generated SVG or PNG pixels; whether a printed symbol scans depends on contrast, size, substrate and preserved quiet zones, which no browser can certify. A physical production sample must still be scanned.

Are bulk PDF label sheets decoded too?

No — the methodology states this as a deliberate exception. Each pasted row, up to 300 lines, is validated before rendering, but the rows of the assembled PDF are not individually decoded. Treat a sheet as validated, not read back, and scan a printed sample.

Math, not optics: this guide describes a check of digits, character sets and rendered pixels; whether a printed symbol scans depends on contrast, size, substrate and preserved quiet zones, so test a printed sample with your own scanner before production or print use. Everything runs locally in your browser. The methodology page draws the full boundary; the guides index covers the other engines.