Verified barcodes.

One campaign, item by item

The barcode maker’s page explains its engine section by section: the input rules, the check-digit arithmetic, the two forms of an ISBN, the cross-check. This guide does a different job. It takes one fictional autumn campaign — a merch product sold at retail, the carton it ships in, a companion book, and a campaign identifier used on internal and inventory materials — and follows each item through the maker: what you have in hand, what you type, what the engine does with it, what it refuses, and what the downloaded file is called. It also shows what happens when a number meant for one symbology is typed into another, which is where campaign work goes wrong quietly.

Every payload, note, error and file name below is produced by the engine at build time from a fixed, labelled input; the date above is the month that reading was done. No platform figure appears here: the system that will read your barcode is the authority on which symbology it expects, so check its own documentation before a print run. The methodology places the engine’s rules beside every other tool’s.

Matching each item to a symbology

The maker’s own guidance is the whole of its advice on this, and it is the only mapping used here: “Use UPC-A or EAN-13 for retail products, ISBN for books, ITF-14 for cartons, Code 39 for constrained legacy systems, and Code 128 for compact campaign or inventory identifiers. A URL still belongs in a QR code.” Read against the campaign:

• The merch product is a retail product, so it takes UPC-A or EAN-13 — whichever number the product line already carries.
• The shipping carton takes ITF-14.
• The companion book takes ISBN.
• The campaign identifier is a compact campaign or inventory identifier, so it takes Code 128 — unless the system it is for is a constrained legacy system that asks for Code 39.
• The campaign’s web address is not a barcode item at all: it goes in a QR code, as the QR codes on promos guide sets out.

The choice matters because it decides which checks run. EAN-13, UPC-A, ISBN and ITF-14 end in a check digit, so for them the engine counts digits and does arithmetic; Code 128 and Code 39 carry no check digit in this tool, so for them it checks the character set and the length and nothing about the digits themselves. The consequences of that split are worked through below.

The merch product: what you have in hand decides the mode

For EAN-13, UPC-A and ITF-14the rule sentence under the data field is the rule — for EAN-13 it reads “12 digits to compute the check digit, or 13 to verify it.” — so enter the data digits and the check digit is computed and appended; enter the full number and the final digit is verified, and a mismatch is refused rather than silently corrected. Which happens depends on what the campaign has in hand. If the product line issued the fictional twelve data digits 501234567890, typing them gets the check digit 0, the payload 5012345678900, and the note “Check digit 0 was independently computed and appended.” If the records already carry all thirteen digits, 5012345678900, typing them gets the same payload with the note “Check digit 0 was independently verified.” The two routes draw the same bars; only the mode on the spec differs — computed or verified— and the status line names it.

A record with one digit mistyped is caught only on the second route. The same number with its last digit altered, 5012345678901, is refused: “Check digit mismatch: the final digit must be 0, not 1.” The engine names the digit it expected and stops there. It has no way of telling which digit the record got wrong — a slip in the final digit and a slip in a data digit produce the same mismatch — so compare with the source document before changing anything. Grouped typing is tolerated: spaces and hyphens are stripped before the digits are counted, so 5012 3456 7890 renders the same payload, 5012345678900.

If the product line carries UPC-A numbers instead, the path is identical at UPC-A’s lengths (“11 digits to compute the check digit, or 12 to verify it.”): the fictional eleven digits 61234567890 become 612345678907with the note “Check digit 7 was independently computed and appended.” The arithmetic behind these digits is set out term by term on the tool page; it is the same routine for every symbology in this section.

The carton: ITF-14 is the same rule at a longer length

The carton takes ITF-14, and ITF-14 follows the same verify-or-compute path one digit longer; its rule reads “13 digits to compute the check digit, or 14 to verify it.” The fictional thirteen data digits 1501234567890 get the check digit 7 and render as 15012345678907, fourteen digits in all. The length that puts ITF-14 in compute mode is the length of a complete EAN-13, which is the first of the traps worked through below: the thirteen-digit merch number 5012345678900, typed with ITF-14 selected, is not refused — it is treated as thirteen data digits, given a fourteenth, and rendered as 50123456789000, a different number from the one on the product. The engine has done exactly what its rule says; the symbology was the wrong one.

The book: type the ISBN as it is printed

The companion book’s number is printed in its ten-character form with hyphens. The ISBN path accepts it as printed — the engine’s test vector 0-306-40615-2 renders 9780306406157with the note “ISBN-10 0306406152 was verified and converted to Bookland ISBN-13.” — and always draws the thirteen-digit form as an EAN-13 symbol, with the renderer format EAN13. The two checks involved (the ten-character check and the thirteen-digit one) are explained on the tool page; for the campaign the point is that the path converts, so what prints under the bars, when the human-readable value is switched on, is the thirteen-digit number, not the ten characters on the book.

Two things the path will not do. It never completes an ISBN-10: the fictional nine digits 123456789alone are refused with “Enter a complete ISBN-10 or ISBN-13.” because a ten-character ISBN already carries its check character and the engine verifies it rather than inventing one. And the ten-character form belongs to the ISBN path only: typed with EAN-13 selected, the same 0-306-40615-2is refused with “EAN-13 needs 12 digits or 13 digits; you entered 10.” because EAN-13 counts digits and knows nothing of the book check. The converted thirteen-digit payload, by contrast, is a valid EAN-13 in its own right: offered to EAN-13 it verifies with “Check digit 7 was independently verified.” So if a book number ever arrives in a spreadsheet of retail numbers, both paths agree on it; only the ten-character form needs the ISBN path.

The campaign identifier: Code 128, and when Code 39 will take it

The identifier PROMO-2026-AUTUMNis a compact campaign identifier, so it takes Code 128. Its rule is “Printable ASCII, 1–80 characters.” and the identifier passes as typed with the note “The encoder automatically chooses and switches Code 128 code sets.” A campaign date typed as an even count of digits, 20261031, changes the note to “Even-length numeric data will use compact Code Set C.” A refusal that is easy to meet in campaign work comes from copying out of a design document: an en dash where a hyphen was meant, as in PROMO–2026, is outside printable ASCII and returns “Code 128 accepts printable ASCII characters in this tool.” Retype the hyphen.

If the system that will read the identifier is a constrained legacy system asking for Code 39, the same identifier carries straight over: Code 39’s rule is “A–Z, 0–9, space, and - . $ / + % only; 1–60 characters.” and PROMO-2026-AUTUMN is made of nothing else, so it is accepted with the identical payload PROMO-2026-AUTUMNand the note “Code 39 character set verified.” The web address does not carry over: offered to Code 39, https://example.com/autumnis refused with “Code 39 supports A–Z, 0–9, space, and - . $ / + % only.” because its colon is outside the set, which is one more reason the address belongs in a QR code.

Code 39 is normalised before it is checked: the value is trimmed and converted to upper case, then tested against the set and the length. An identifier pasted with stray spaces and in lower case, promo 42/b , renders the payload PROMO 42/Bwith the note “Lowercase letters were converted to uppercase for Code 39.” — the note is chosen by whether the upper-casing changed anything. The payload, not what you typed, is what the bars encode and, when the human-readable value is switched on, what prints under them.

Carrying a number into the wrong symbology

Two rules explain every case in this section: the length of what you type decides whether a check-digit symbology computes or verifies, and the symbology you selected decides which two lengths it accepts. The engine never asks whether the number was meant for the symbology it was given. Worked on the merch number:

• The thirteen-digit 5012345678900typed with UPC-A selected is refused with both of UPC-A’s lengths spelled out: “UPC-A needs 11 digits or 12 digits; you entered 13.” A refusal is the good outcome: nothing wrong gets drawn.
• The twelve-digit UPC-A number 612345678907 typed with EAN-13 selected is not refused. Twelvedigits is the first length in EAN-13’s rule (“12 digits to compute the check digit, or 13 to verify it.”), so the engine computes and appends a check digit and renders 6123456789078 — thirteen digits where the product carries twelve. The note (“Check digit 8 was independently computed and appended.”) and the status line’s mode computed both say that a digit was added; neither can say that the number you typed was already a complete UPC-A, because the engine never asks. That is why reading the mode matters when the records carry a full number: a computed digit on a number that should have been verified means the wrong symbology is selected.
• The same thirteen digits typed with ITF-14 selected gain a fourteenth, as the carton section showed.

The quietest case is Code 128. The full merch number 5012345678900is printable ASCII within the length limit, so Code 128 accepts it with the note “The encoder automatically chooses and switches Code 128 code sets.” and no check digit on the spec. So does the mistyped version that EAN-13 refused: 5012345678901 passes Code 128 with the same note, and the cross-check, having no digit to re-verify, returns true. A wrong digit sails through, correctly, because the check-digit arithmetic runs only when a check-digit symbology is selected. “Verified” on this page means verified by the rules of the symbology you chose.

Two routes to every printed digit

For each item, validation produces a spec: the symbology, the payload to draw, the renderer format and, for EAN-13, UPC-A, ISBN and ITF-14, the check digit with its mode. Before the renderer sees it, the tool runs crossCheckBarcode, which re-verifies the payload’s final digit by an independent route and compares it with the digit on the spec. On the merch number it returns true; on the campaign identifier, where there is no digit to re-verify, it passes the spec through and returns true. Were the two routes ever to disagree, the tool would withhold the barcode; its current wording for that is “Independent check-digit verification failed; the barcode was withheld.”

The status line under the settings reports the result. While a value is refused, the engine’s error replaces that line and the preview stays empty; once a value is accepted, the line names the digit and its mode — on the computed merch number the tool’s current wording reads “Check digit 0 computed and re-verified.” and for Code 128 or Code 39 it reads “Payload and character set verified.” The note beneath the preview is the spec’s note, word for word, as quoted throughout this guide.

Naming the files for the campaign folder

Each item downloads as a PNG or an SVG of the same symbol; the tool page describes how the two files are produced from the preview. Both are named from the symbology and the payload, with the payload slugified: lower-cased, every run of characters outside letters and digits replaced by one hyphen, hyphens at either end removed, and the word promo used if nothing is left. Across the campaign that gives:

Three things to read off that table. The name carries the rendered payload, so a computed check digit or a converted ISBN is in the file name as well as under the bars, and a file name can be checked against the records. The same identifier rendered in Code 128 and in Code 39 produces two files that differ only in their prefix, so the prefix is the only record of which symbology was drawn: keep it. And a slug is lossy — a web address rendered in Code 128 would be named code128-https-example-com-autumn.svg, and a Code 39 value made only of its symbol characters, the fictional $/+%, leaves no letters or digits at all and is named code39-promo.svg— so the file name is a label, not a copy of the payload. The PNG of each item is the same name with its own extension, as in ean13-5012345678900.png.

What the maker leaves to the workflow

The engine checks arithmetic and character sets. It does not issue, register, look up or reserve numbers; it cannot tell whether a number is yours or in use; and it cannot tell whether the symbology you selected is the one the system that will read the code expects — the mapping quoted above is the extent of its advice, and that system’s own documentation is the authority. Nothing in the maker reads a finished symbol back, and the colours are drawn as chosen with no check of their own — both are set out under “Where the tool stops” on the tool page. There are exactly 6 symbologies; anything else, and any URL, belongs in the QR tool.

The tool page’s three handling notes carry over unchanged: “Short identifiers produce less dense bars and are generally easier to reproduce.” “Do not crop the open space on either side of the downloaded barcode.” and “Dark bars on a clean light background provide the strongest scanner reliability.” For the campaign’s printed pieces, the event promotion checklist covers the QR code that sits beside these barcodes: one destination, the quiet zone kept clear, dark modules on a light background, and SVG export for print.

Questions

My records carry the full product number. Do I type all of it or leave the last digit off?

Either works for EAN-13, UPC-A and ITF-14, and the status line tells you which happened. Type the data digits and the check digit is computed and appended ("Check digit 0 was independently computed and appended."); type the full number and the final digit is verified ("Check digit 0 was independently verified."). Typing the full number is the route that catches a mistyped record: a wrong final digit is refused with the expected digit named, as in "Check digit mismatch: the final digit must be 0, not 1."

Why did my twelve-digit UPC-A number come out as thirteen digits?

Because EAN-13 was selected. Its rule is "12 digits to compute the check digit, or 13 to verify it." and twelve digits is its first length, so the engine treated the number as data, computed a check digit and appended it: 612345678907 rendered as 6123456789078. The note reads "Check digit 8 was independently computed and appended." and the status line's mode reads "computed". Select UPC-A and the same twelve digits are verified instead.

Can I type the ISBN exactly as it is printed on the book, hyphens and all?

Yes, with ISBN selected: "0-306-40615-2" renders 9780306406157 with the note "ISBN-10 0306406152 was verified and converted to Bookland ISBN-13." The thirteen-digit form is what the bars encode and, when the human-readable value is switched on, what prints under them. The ten-character form is accepted by the ISBN path only; offered to EAN-13 it is refused with "EAN-13 needs 12 digits or 13 digits; you entered 10."

If I render a product number as Code 128, is its check digit verified?

No. Code 128 carries no check digit in this tool, so the engine checks only the character set and the length: 5012345678900 passes with "The encoder automatically chooses and switches Code 128 code sets." and so does the mistyped 5012345678901. The check-digit arithmetic runs only when EAN-13, UPC-A, ISBN or ITF-14 is selected.

Can I put the campaign's web address in a barcode?

Code 128 accepts a short address as printable ASCII — the fictional "https://example.com/autumn" passes with "The encoder automatically chooses and switches Code 128 code sets." — but Code 39 refuses it ("Code 39 supports A–Z, 0–9, space, and - . $ / + % only."), and the tool page's guidance stands: a URL belongs in a QR code.

What is the difference between the PNG and the SVG downloads?

Both are exported from the same verified payload and carry the same name apart from the extension, as in ean13-5012345678900.svg and ean13-5012345678900.png. The SVG keeps the symbol as vector shapes; the PNG is a bitmap of it at a fixed scale. The tool page describes how each is produced from the preview.

Does the tool check that a number is registered or belongs to my product?

No. It checks arithmetic and character sets on the device, with no product database. A verified check digit means the final digit agrees with the digits before it, and nothing more; which symbology the reading system expects is decided by that system's documentation, not by the tool.