UPC-A Barcode Generator

A rendered symbol is not a registered number

Before printing this on anything you plan to sell: UPC numbers are licensed, not generated. Retailers and marketplaces increasingly validate GTINs against the GS1 registry, and a number nobody licensed to you will be rejected — or worse, collide with someone else's product. What this tool legitimately does is render numbers you already have the right to use: GTINs from your GS1 prefix, internal codes for a closed store system, or samples for design mockups. Unsure which case you are in? Start with Do I need a GS1 barcode?; this page stays on the arithmetic.

What the validator does with eleven or twelve digits

Four things happen to your input, in order, before the renderer is asked for a single bar. Normalise: spaces and hyphens are stripped, so a number pasted with whatever grouping a label or spreadsheet gave it — 036-000 291-452, say — becomes the same twelve digits, 036000291452. Enforce: what remains must be digits 0–9 only, and exactly 11 or 12 of them. Compute or verify: with 11 digits the check digit is computed and appended; with 12, the final digit is verified against the first eleven. Report: whichever happened is written into the notes shown under the barcode, never applied invisibly.

Anything outside those rules is refused with a message naming the rule, and the flow stops there — no bars are requested from the renderer. Ten digits: "A UPC-A needs 11 digits (check digit computed) or 12 digits (check digit verified) — you entered 10." A letter O typed where a zero belongs (O3600029145): "A UPC-A contains digits 0–9 only (spaces and hyphens are ignored)." Thirteen digits, the EAN-13 form of a UPC: "A UPC-A needs 11 digits (check digit computed) or 12 digits (check digit verified) — you entered 13." For that last case, drop the leading zero or use the EAN-13 generator.

UPC-A is EAN-13 wearing a shorter coat

The two symbologies share one numbering system (GTIN) and one check-digit algorithm. Worked at build time by this site's engine: data digits 03600029145 require check digit 2, giving the complete UPC-A 036000291452 — and its EAN-13 form 0036000291452 yields the identical check digit 2, because a leading zero adds nothing to the weighted sum. That equivalence is why an EAN-13 generator will accept your UPC with a zero in front, and why scanners report either form interchangeably.

Leading zeros never change a GTIN check — a structural property the methodology page records the test suite confirming — so the EAN-13 validator reads the zero-prefixed form as a complete number. Paste 0036000291452 into the EAN-13 generator and its note reads: "You entered all 13 digits — the check digit 2 was verified against the first 12 and is correct."

After rendering, the comparison that follows independent decoding accepts the decoder's text only if it is the validated twelve-digit payload or those digits with a zero in front — the two ways a reader may spell the same printed symbol: for 036000291452 it accepts 036000291452 and 0036000291452, and rejects 036008291452, withholding the barcode rather than relabelling it.

The mod-10 check, from the UPC side

In UPC terms: add the digits in the odd positions (first, third, fifth…), triple that sum, add the digits in the even positions, and the check digit is whatever lifts the total to a multiple of ten. It is the same 3-and-1 weighting as EAN-13, just described from the other end — both are anchored at the rightmost data digit, which always carries weight 3.

The same arithmetic on the cited walkthrough number, every figure computed at build time:

The guide How GTIN check digits are computed works the same arithmetic on a fictional number and sets compute mode beside verify mode; to run any GTIN length by hand, use the check digit calculator.

Why a mismatch is an error, not a correction

Take the complete number 036000291452 and corrupt one data digit — position 6, 0 mistyped as 8 — while keeping the original check digit: 036008291452. Twelve digits, so the validator verifies, and its answer is:

The message names the digit the first eleven require, the one you typed, and two routes — fix the number, or enter only the first 11 digits. It does not take the second route for you: a failing check digit is as likely to mean one of the other digits is wrong as the last one, and silently substituting the expected digit would turn a detectable error into a valid wrong number. With twelve digits the tool verifies; it computes only when you give it eleven.

A fictional number shows what the check digit does and does not catch: 72041583960, whose check digit the engine computes as 5, giving 720415839605. Swap positions 3 and 4 and the validator refuses 724015839605: "Check digit mismatch: for 72401583960 the final digit must be 7, but you entered 5. Fix the number, or enter only the first 11 digits to have the check digit computed." Swap positions 1 and 2 instead and 270415839605 passes — "You entered all 12 digits — the check digit 5 was verified against the first 11 and is correct." — because those two digits differ by 5, and exchanging a 3-weighted and a 1-weighted digit that differ by 5 moves the weighted sum by a multiple of ten. Every single-digit error is caught — a property the methodology page's tests confirm — but not every adjacent transposition.

Verified before you download it

Every barcode this page shows has passed a chain of checks, each with a stated scope. Structure and check digit, as above, before the drawing library receives the accepted payload. A payload cross-check that re-derives the check digit inside the accepted payload — inspecting the string, not the bars. Then independent decoding: the SVG actually shown is rasterized and read by ZXing, a decoding engine independent from the renderer; the preview and downloads stay withheld when it cannot read the image or reads a different payload, and the message says which. PNG export is decoded again from its own canvas; the single-barcode PDF translates the decoded SVG's rectangles and caption into native vector geometry rather than embedding a screenshot.

These checks cover generated files, not physical print quality — the methodology page draws that line, and How the verifier decodes what you see explains what is withheld and why.

ZPL export carries eleven digits, and says so

The ZPL download is a text document of commands the printer's own barcode engine draws from. The export insists on the full validated twelve-digit payload — hand it the eleven data digits and it refuses: "UPC-A ZPL export needs the full 12-digit payload including the check digit, exactly as the generator produced it — received "03600029145" (11 characters)." Given 036000291452 it verifies the check digit once more, then sends only the data digits — ^FD03600029145^FS — because the printer recomputes the check digit itself, as the export's note says: "The ^FD data carries only the data digits — the printer recomputes the check digit and arrives at the same 2 for this UPC-A that our validator already verified." ZPL and EPS export explained covers the rest of the document.

Print size and quiet zones

GS1 size guidance calls for light margins of at least 9 module widths on each side of a UPC-A symbol (GS1 size guide). The downloads include those quiet zones. Beyond the margins, the advice is qualitative but firm: print dark bars on a light background, do not scale below the sizes your print process can hold cleanly, and test the result with a real scanner — the supermarket laser is the only judge that counts.

The methodology page cites one further figure from the GS1 member-organisation size guides it links — a consumer X-dimension (module width) range of 0.264–0.660 mm — and otherwise keeps print guidance qualitative; you will not find an invented DPI table here.

Where the arithmetic stops

Math, not optics. This page verifies digits; whether a printed symbol scans depends on contrast, size, substrate and preserved quiet zones, none of which a browser can certify — a physical production sample must still be scanned. Symbols, not numbers. Generating a UPC-A barcode does not allocate or license the GTIN inside it; that is GS1's role, and a correct check digit says nothing about it. Local processing. Inputs never leave your device. For a whole column of numbers, the check digit calculator validates in bulk — in its auto mode a twelve-digit line is read as a complete UPC-A and verified, never repaired; in data-only mode the same line is treated as GTIN-13 data digits — as Bulk GTIN validation modes explains.

UPC-A FAQ

Verify before production: mathematics checked here, optics checked by your scanner — always test the printed symbol. Everything runs locally in your browser; see the methodology page. Numbering items that never leave your own store? The in-store barcode guide explains number system 2 and 4 prefixes.