Text & everyday tools · QR & Barcode Toolkit
How the Code 128 check digit works: a modulo 103 walkthrough
· How it works
encoding validation developer-workflow
Computes the Code 128 check character by hand for a short label, explaining the weighted sum, the modulo 103 step and why the scanner rejects a label when the sum is wrong.
A rejected or misread label needs diagnosis; the check character is only one possible cause
A scanner returning nothing does not prove the check character caused the failure; quiet-zone damage, print quality or unsupported input can produce similar symptoms. What the repository proves is that generated Code 128 includes a calculated check symbol before the stop pattern.
A clean failure investigation starts with the exact returned text and the physical label. ToolAcre guarantees that its generated binary begins with a valid start pattern and ends with the fixed stop pattern; it cannot inspect a scratched print, a scanner configuration or an application that rejects the decoded identifier. Regenerating the same value as SVG and scanning a fresh proof helps distinguish encoding from damage before anyone blames the checksum.
Symbol values, not ASCII codes — how Code 128 assigns each character a value from 0 to 102 within a code set
Code 128 works with symbol values rather than simply adding the displayed ASCII byte values. ToolAcre delegates set selection and symbol construction to JsBarcode’s CODE128_AUTO encoder, then validates that the returned pattern is made only of binary modules.
The distinction is visible when the automatic encoder changes sets. A displayed digit does not carry one universal checksum number independent of context; its symbol value depends on the active Code 128 set, and set C can represent a pair of digits as one symbol. That is why adding ASCII character codes by hand is the wrong model. The checksum must follow the actual emitted symbol sequence, including any set changes chosen by the encoder.
The weighted sum — start code counts once, then every symbol is multiplied by its position and added up
The checksum begins with the start symbol value, then weights each following data symbol by its one-based position. That positional weighting means exchanging two symbols usually changes the sum even when the set of displayed characters stays the same.
Position zero is special: the start value enters once, while each following symbol is multiplied by its one-based data position. This makes the checksum sensitive to order. Two shelf codes containing the same characters in different positions usually produce different remainders, which is precisely the useful failure signal when a bar is misread or a label is generated from transposed source data.
Modulo 103 — why 103 and not 100, and how the remainder becomes the check character drawn before the stop pattern
Taking the weighted sum modulo 103 produces the check-symbol value placed immediately before the stop pattern. The repository tests this invariant by parsing generated symbols and recomputing the remainder, not by trusting the human-readable caption.
The remainder fits one normal Code 128 symbol value, so it can be inserted before the terminator and checked by a reader without adding visible text. ToolAcre delegates that insertion to CODE128_AUTO and then treats the returned binary as the artifact. Its own second gate rejects an invalid encoder result rather than attempting to repair or guess a pattern that the dependency said was not representable.
Worked example: inspect the generated symbol sequence without inventing an unsupported hand result
Enter A12-07 and ToolAcre builds the start, data, check and stop symbols as one binary pattern. The source does not publish a hand-derived symbol table for this exact string, so this walkthrough stops at the verified algorithm rather than inventing a remainder.
A responsible worked check therefore starts from the generated artifact. Enter `A12-07`, retain that exact source value, and confirm the exported barcode’s accessible label and optional caption still show `A12-07`. A separate standards-aware decoder can inspect symbols if a hand calculation is required. This repository does not expose the intermediate values, so publishing a numeric remainder here would be an unsupported reconstruction rather than evidence from ToolAcre.
Why you never type the check character yourself — the generator appends it, and a hand-typed one would be checksummed again
Do not append a check character to the text field. The encoder treats every typed character as payload, then computes a new check symbol over that expanded payload, leaving scanners to return an extra data character you never intended.
The extra-character failure is easy to reproduce conceptually. If a warehouse procedure tells staff to append a supposed check character, ToolAcre receives it as ordinary payload and the library calculates another check over the longer string. A scanner then returns the appended character as data. The database lookup fails even though checksum validation succeeds, because generation protected the wrong identifier perfectly.
What this does not cover — GS1-128 application identifiers and the mod 10 check digits used by EAN and UPC
This calculation does not create GS1-128, EAN or UPC. The toolkit generates ordinary Code 128 and has no FNC1 or retail-number allocation workflow, while its configuration explicitly places those other symbologies outside the tool’s scope.
GS1 and retail checks belong to different workflows because their data structure is more than a final arithmetic step. ToolAcre has no FNC1 control, application-identifier parser, GTIN allocation check or EAN/UPC output. A supplier label requiring any of those cannot be made compliant by copying bracketed text or a mod-10 digit into this plain Code 128 field.
The takeaway — the QR & Barcode Toolkit computes and appends the check character in your browser, so you only type the data
The practical division is simple: type only the shelf identifier, let the encoder select code sets and calculate modulo 103, then preserve the generated quiet zones. ToolAcre performs that sequence locally and exports the resulting bars as SVG or PNG.
Keep the human source of truth beside the generated file: the literal identifier, its owner and a test scan result. If a later print fails, regenerate from that value rather than tracing bars by eye. The browser generator removes one manual checksum opportunity, while preserving the operational need to verify quiet zones, print quality and byte-for-byte lookup against the inventory system.