UPC-A check digit

Retail product numbers in North America almost always end with a UPC-A check digit: eleven payload digits that identify the manufacturer and item, plus one trailing digit that proves the whole string was typed or scanned without a single-digit slip. This capability implements the standard GTIN-12 mod-10 rule used on every twelve-digit UPC-A: odd positions from the left are weighted by three, even positions by one, and the check digit is the amount needed to reach the next multiple of ten. Non-numeric input and wrong lengths fail with invalid_input instead of silent stripping, so you never store a half-cleaned code. The same pure arithmetic runs free in the browser and at the published API price.

How the UPC-A check digit is calculated

To compute it, walk the eleven payload digits from left to right with 1-based positions: multiply each odd-position digit by three and each even-position digit by one, add those products, then take the check digit as (10 minus that sum modulo 10) modulo 10. Compared with multi-symbology barcode validators, the search intent here is narrow: people who need the UPC-A check digit calculator for eleven-digit payloads, not a general EAN-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—eleven for compute, twelve for validate—so client forms can show “need eleven 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 product numbers; prefer validate when you gate a lookup or import on a full code from a user or partner file. 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 eleven digits, returns check_digit as a one-character string, and returns with_check as the twelve-digit UPC-A you can print or persist. Mode validate requires exactly twelve digits; the response reports valid true when the trailing digit matches the recomputed expected_check_digit, and always includes payload (the first eleven digits), check_digit, expected_check_digit, and length twelve. Alias keys such as digits, upc, and code are accepted for the same payload field so integrations that already speak “upc” 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 UPC-A check digits fit real workflows

Catalog and PIM teams receive eleven-digit internal product numbers and must append the official UPC-A check digit before printing shelf labels or pushing to marketplaces that reject invalid GTINs. Warehouse scanners and receiving apps validate twelve-digit codes at the dock so a single transposition does not create a phantom SKU and a stock mismatch. Data-quality jobs walk every UPC column in a CSV export, call validate mode, and quarantine rows where valid is false—catching both human edits and off-by-one bugs in generators. E-commerce onboarding forms can recompute expected_check_digit and show a friendly correction when a seller pastes a code with a mistyped last digit. Do not treat a passing UPC-A check as proof of brand ownership or GS1 registration; it only proves the mod-10 digit is consistent with the payload under the standard weights.