Building a Code 128 Barcode: Code Sets, Checksum, and Common Failures

Published 2026-08-19 · Updated 2026-08-19

Code 128 is a linear symbology that can encode the full ASCII character set by switching between three code sets (A, B, and C) within a single symbol, and every valid Code 128 symbol carries a mandatory, automatically calculated checksum. A generator that lets you type arbitrary text and renders a symbol has already made the code-set and checksum decisions for you.

What Code Set A, B, and C actually change

Code 128 encodes the full ASCII character set, but it does that by switching between three internal code sets rather than using one fixed alphabet. Code Set A covers uppercase letters, digits, punctuation, and non-printable control characters; Code Set B covers uppercase and lowercase letters, digits, and punctuation; Code Set C packs two digits into a single symbol character, which makes it noticeably more compact for long numeric strings such as an internal serial number. A generator that accepts free text and produces a Code 128 symbol has to decide, character by character, which code set minimizes the encoded length or matches an application's constraints, and it can switch mid-symbol when that produces a shorter or more appropriate result. You do not need to choose the code set yourself for ordinary text; you do need to know that a long digit-only string usually renders more compactly than the same length of mixed-case text, because Code Set C is doing more work per symbol character.

The checksum is not optional and you do not calculate it

Every Code 128 symbol includes a modulo-103 checksum character, calculated from the start character and every data character's weighted value, and a symbol without a valid checksum is not a Code 128 symbol at all — a compliant decoder refuses to report a result rather than return unverified data. This is different from EAN-13 or UPC-A, where the check digit is one of the printed digits you can read and verify with a simple calculator. In Code 128 the checksum character is part of the encoded pattern, not something a human reads off the label, so a generator handles it automatically and there is no manual arithmetic step to double-check by eye. If a decoded value looks wrong, the checksum has already ruled out the most common transcription-style error; the more likely cause is that the wrong source data was fed to the generator in the first place.

Worked example: encoding BOX-2026-0042

Take the identifier BOX-2026-0042, a plausible internal label for a storage container. Entered into a Code 128 generator, the software will typically render the letters and hyphens in Code Set B, since that set covers mixed-case text and the punctuation used here, and may switch to Code Set C for the run of digits if that produces a shorter symbol. The rendered result should read back locally as exactly BOX-2026-0042, with no extra characters, no case change, and no substituted symbol for the hyphen. If a read-back check shows a different string — a common failure is a hyphen rendered as a different punctuation mark by a font substitution earlier in the design file — the fault is in the source text or the export pipeline, not in the Code 128 checksum, which would already have rejected a genuinely corrupted pattern.

When Code 128 stops being enough: GS1-128

Code 128 becomes GS1-128 only when the data follows GS1's Application Identifier structure and the symbol begins with the FNC1 non-printable character immediately after the start character, signalling to a compliant receiving system that the following digits should be parsed as one or more Application Identifier fields rather than as an arbitrary string. Printing visible parentheses around what looks like an Application Identifier does not make a symbol GS1-128; the FNC1 character is what actually carries that meaning to the decoder. If a logistics label needs to carry a GTIN, a batch or lot number, and an expiry date together in one scan, it needs the FNC1-qualified GS1-128 structure and a receiving system built to parse it, not a plain Code 128 string that happens to contain similar-looking digits.

Mistakes that produce a technically valid but useless label

A common failure is generating a Code 128 label from a spreadsheet column that stores an identifier as a number, silently dropping a leading zero that the receiving database expects — the symbol renders and decodes correctly, but as the wrong string. Another is copying text from a word processor that has replaced a plain hyphen with an en dash or a straight quote with a curly one; Code 128 can encode many of these characters, so the generator does not object, but the receiving system's exact-match lookup fails because the character is not the one it expects. A third is assuming that because a symbol scans on a phone camera app, it will scan identically on the fixed industrial reader it is actually destined for; test on the intended reader, not a convenient substitute.

Testing a Code 128 export before it leaves the building

Before a Code 128 label leaves a design file, decode the exported artwork — not a screen preview — and compare the result character by character against the source value, watching specifically for case, punctuation, and leading zeros. Print a small physical proof on the actual substrate and test it with the reader that will be used in production, since a phone camera's more forgiving optics can mask a module width or contrast problem an industrial scanner will not tolerate. Keep the source string, the generator settings, and the confirmed read-back result together as a small record; when a label is reprinted months later from a saved file, that record is what proves the new copy still encodes the same value as the original approval.

What a Code 128 generator cannot decide

A Code 128 generator cannot tell you whether the identifier you are encoding is unique within your own system, whether a receiving application expects Code Set A, B, or C behaviour that differs from the generator's automatic choice, or whether a legacy scanner in the field actually supports Code 128 at all rather than only Code 39. It also cannot enforce a business rule such as a fixed identifier length or a required prefix; those checks belong in the system generating the source values, before the string ever reaches the barcode step. Use a Code 128 generator for what it does well — turning a correct string into a correctly checksummed, correctly code-set-switched symbol — and keep the correctness of that string as a separate, earlier responsibility.

Reading a Code 128 symbol's start character to confirm the code set

A Code 128 symbol opens with one of three start characters — Start A, Start B, or Start C — that tells a decoder which code set the encoded data begins in, and a diagnostic-capable reader or software decoder can usually report which start character it found. If a symbol was expected to render in Code Set B for a mixed-case identifier but a diagnostic tool reports Start C, that mismatch is worth investigating before blaming the scanner: it can mean the generator chose a different, still-valid encoding path than expected, which is normal, or it can mean the source string was not what the operator intended, which is not. Checking the reported start character during initial testing gives an extra, independent confirmation beyond the decoded text alone, and it costs nothing beyond using a decoder that exposes it rather than only the final string. The same diagnostic habit is worth applying whenever a Code 128 label produced by one system needs to be matched against a label produced by a different generator for the same identifier, since two implementations can both encode a string correctly while choosing a different code-set path to get there — the decoded text will match, but the underlying symbol shape and start character can differ, which is expected and not itself a defect. Treat a start-character mismatch as a prompt to compare the decoded strings carefully rather than as proof of an error on its own, and only escalate it if the actual decoded text, not merely the internal encoding choice, disagrees between the two labels. ISO/IEC 15417:2007 Code 128 bar code symbology specification is the named source for the current external rule or product behaviour.