ITF-14 Barcode Generator

Interleaved: digits ride in pairs

In Interleaved 2 of 5, digits are encoded two at a time — the first of each pair as the widths of five bars, the second as the widths of the five spaces between those bars. Nothing is wasted on separators, which makes ITF dense and tolerant of coarse printing, and it makes an odd number of digits physically impossible: there is no such thing as bars without their spaces. Hence the even-digit rule, and hence ITF-14's fixed length of 14.

What the validator does before any bars are drawn

The rule under the input field reads “13 digits (check digit computed for you) or 14 digits (check digit verified).” The validator enforces it in four steps, in this order, before the renderer is asked for anything.

1. Normalise. Spaces and hyphens are stripped, because packing lists print numbers that way. Paste 0 950600 013435 2 and the payload becomes 09506000134352. Nothing else is touched — no trimming, no padding with a leading zero: the even-digit rule is enforced as a length rule.
2. Enforce. What remains must be digits only, exactly thirteen or fourteen of them. A letter anywhere produces “A ITF-14 contains digits 0–9 only (spaces and hyphens are ignored).” The twelve item-level data digits of a fictional product, 731408823416, are one short: “A ITF-14 needs 13 digits (check digit computed) or 14 digits (check digit verified) — you entered 12.”
3. Compute or verify. Thirteen digits are data: the engine computes the fourteenth and appends it. Fourteen are a complete number: the engine recomputes the check digit from the first thirteen and compares. The digit count alone decides the mode.
4. Report. What happened is written into the note under the barcode — in compute mode, for GS1's published example data, “You entered 13 digits — the check digit 2 was computed and appended, making 09506000134352.” and in verify mode, for the complete fourteen digits, “You entered all 14 digits — the check digit 2 was verified against the first 13 and is correct.” Only then does the accepted payload, exactly 09506000134352, go to the rendering library; a failure at any step stops the flow and no bars are drawn.

The check digit, worked by this site's engine

Weights 3 and 1 alternate across the thirteen data digits, anchored at the rightmost digit, which always carries 3; the check digit is whatever lifts the sum of the products to the next multiple of ten.

The same arithmetic with its intermediate values exposed, on a fictional carton number — indicator 1 in front of the fictional item data 731408823416, thirteen data digits 1731408823416:

The guide How GTIN check digits are computed walks these steps on the cited reference vectors for every GTIN length and sets compute mode beside verify mode; this page keeps to ITF-14. The guides hub lists the rest, and the check digit calculator runs the same routine over up to 500 lines at once.

Why the indicator digit changes the check digit

A carton code is built from an item number. Take a fictional item whose twelve data digits are 731408823416: their EAN-13 check digit is 9, so the item number is 7314088234169. To make its GTIN-14, drop that check digit, put an indicator in front of the twelve, and compute a new check digit over all thirteen:

Compare each final digit with the item's own check digit, 9. The weights are anchored on the right, so the twelve item digits keep the weights they had inside the EAN-13; the indicator occupies the leftmost position, which carries weight 3, and its product joins the sum, so the old check digit no longer balances. Only an indicator of 0 leaves the sum untouched — which is why 950600013435, the cited example without its leading zero, computes to the same check digit 2 as the fourteen-digit 09506000134352.

This is the misreading the tool cannot catch for you. Paste the complete item number 7314088234169 into the ITF-14 field and its thirteen digits select compute mode: the check digit 9 is treated as data and a fresh one is appended, producing 73140882341696 — a number that passes every check this page runs and is still not the carton code, which is 17314088234166 with indicator 1. Thirteen digits look the same to arithmetic whether they are indicator-plus-data or data-plus-check; only you know which you typed.

How to read a mismatch — and what a pass does not mean

Change one digit of the cited example — here the seventh, 0, becomes 1, giving 09506010134352 — and verify mode reports valid: false, expected 9, supplied 2. On the page that becomes the error “Check digit mismatch: for 0950601013435 the final digit must be 9, but you entered 2. Fix the number, or enter only the first 13 digits to have the check digit computed.”

Read it as a statement about the whole number, not its last digit. The engine names the digit the first thirteen would require because that helps locate the typo, but never applies it: the data is as likely to be at fault as the check, and substituting the expected digit would turn a detectable error into a valid wrong number — hence the only two options the error offers, fix the number or enter the thirteen data digits alone.

What a pass means is narrower than it feels. A mod-10 check digit catches every single-digit error — changing one digit moves the weighted sum by one or three times a non-zero difference, never a multiple of ten — a property this site's tests confirm. It does not catch everything: adjacent positions carry weights 3 and 1, so swapping two neighbouring digits shifts the sum by twice their difference, and when that difference is five, or zero, the shift is a multiple of ten the check digit cannot see. On the cited example, swapping the first two digits gives 90506000134352, which is caught — expected 4, supplied 2; swapping the third and fourth gives 09056000134352, which passes verification unchanged. A number that passes is internally consistent — that is all the arithmetic can say.

Verified before you download it

The four validation steps are arithmetic over the string you typed; the accepted payload is then cross-checked by recomputing its check digit independently — for the computed example on this page that cross-check agreed at build time, as it must. Only after that is the SVG shown on the page rasterised and read by ZXing, a decoding engine independent of the renderer. The decoded text must match the validated payload digit for digit (the one leading-zero equivalence the comparison allows applies only between UPC-A and EAN-13), and the stage refuses for two reasons — the decoder could not read the rendered bars, or it read a different text, which the message quotes — withholding the preview and download controls either way. PNG export is decoded again from its own canvas before the file is released; the single-barcode PDF translates the decoded SVG's rectangles and caption into native vector geometry; bulk PDF label sheets are the deliberate exception, validated row by row but not decoded.

All of this covers generated files, none of it ink, fibreboard, scaling, contrast or the quiet zones left after printing — math, not optics. The methodology page draws the boundary, and the guide How the verifier decodes what you see explains the withholding rules.

Bearer bars, quiet zones, and honest limits

Printed carton symbols are usually framed by a heavy bearer bar, which GS1 guidance calls for when printing on fibreboard — it equalizes plate pressure and stops a skewed scan from reading a partial symbol. This tool's downloads contain the bars and human-readable digits only, without a bearer bar; carton artwork normally adds it at the print stage. Quiet zones of at least 10 module widths on each side are included in the downloads (per GS1 size guidance, which also puts the carton-grade module width at roughly 0.5–1.0 mm — ITF-14 is a physically large symbol, over 14 cm wide at nominal size per GS1 Ireland). Scale the SVG accordingly rather than shrinking it to fit a label designed for EAN-13.

The ZPL download, built for the cited example, says the same in its own notes:

• ITF-14 bearer bars are not added by ^B2 — print inside a frame or use label software for bearer bars.
• 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.

Its field-data line is ^FD09506000134352^FS — all fourteen digits, check digit included — because for ITF-14 the engine sends the complete validated number; the EAN and UPC exports strip the check digit because the printer recomputes it. The ZPL printing guide and ZPL and EPS export explained cover the rest.

Symbols, not numbers

Everything on this page is arithmetic over digits you already hold. Generating an ITF-14 does not allocate or license the GTIN inside it — that is GS1's role — and the indicator digit and recomputed check digit transform an item number; they do not supply one. If you are still deciding whether your product needs a licensed number, start with Do I need a GS1 barcode? This page gives no licensing advice.

ITF-14 FAQ

Verify before production: warehouse scanners meet worse printing than any other barcode environment — test a real printed carton, not just the screen. GS1 numbering rules apply: the GTIN inside an ITF-14 must be licensed like any retail number. Everything runs locally in your browser; see the methodology page. Printing cartons on a Zebra-family thermal printer? The ZPL printing guide covers the native ZPL download and its ITF-14 caveats.