GTIN-14 check digit

This capability implements the standard mod-10 rule on a thirteen-digit payload—weights counted from the right, odd positions times three, even positions times one—and either returns the check digit plus the completed fourteen-digit string, or validates a full fourteen-digit code with an explicit valid flag and the expected digit. Non-numeric input and wrong lengths fail with invalid_input instead of silent stripping, so you never store a half-cleaned case code. The same pure arithmetic runs free in the browser and at the published API price for automation.

How the GTIN-14 check digit is calculated

To compute it, take the thirteen payload digits and walk them from right to left: multiply the rightmost payload digit by three, the next by one, alternating, then form the check digit as ten minus that weighted sum modulo ten, modulo ten again so a zero remainder yields check digit zero. Compared with multi-symbology barcode validators, the search intent here is narrow: people who need a GTIN-14 check digit calculator for thirteen-digit payloads, not a general UPC-or-ISBN checker.

Input contract, modes, and error behaviour

Send a number field that contains only characters zero through nine. Wrong length is an explicit error that names the mode and the length you sent—thirteen for compute, fourteen for validate—so client forms can show “need thirteen digits” without guessing. Empty strings, missing number, and invalid mode values fail before any weighted sum runs and are not billed. Prefer compute when you mint or complete logistics GTINs from an indicator plus base; prefer validate when you gate a warehouse scan, ASN line, or partner file import on a full fourteen-digit code. Spaces, hyphens, letters, and decimal points are rejected as non-numeric input with invalid_input so a silently stripped value never reaches storage. Mode compute is the default: the engine requires exactly thirteen digits, returns check_digit as a one-character string, and returns with_check as the fourteen-digit GTIN-14 you can print on a case label or persist in a PIM. Mode validate requires exactly fourteen digits; the response reports valid true when the trailing digit matches the recomputed expected_check_digit, and always includes payload (the first thirteen digits), check_digit, expected_check_digit, and length fourteen. Alias keys such as digits, gtin, and code are accepted for the same payload field so integrations that already speak “gtin” do not need a rename. Because the path is pure parse with no clock, random source, or network, the same JSON body always yields the same JSON result on the free browser tool and on the API at $0.002 per successful request.

Where GTIN-14 check digits fit real workflows

Warehouse and logistics teams receive thirteen-digit internal case numbers—indicator plus consumer GTIN body without check—and must append the official GTIN-14 check digit before printing ITF-14 or GS1-128 labels for pallets and outer cartons. Receiving apps validate fourteen-digit codes at the dock so a single transposition does not create a phantom case SKU and a stock mismatch against the ASN. Data-quality jobs walk every GTIN-14 column in a catalog or EDI export, call validate mode, and quarantine rows where valid is false—catching both human edits and off-by-one bugs in generators that padded GTIN-13 incorrectly. E-commerce and marketplace onboarding forms can recompute expected_check_digit and show a friendly correction when a seller pastes a case GTIN with a mistyped last digit. Do not treat a passing GTIN-14 check as proof of brand ownership, packaging hierarchy correctness, or GS1 registration; it only proves the mod-10 digit is consistent with the thirteen-digit payload under standard GS1 weights.