Why a Code 128 Barcode Scans as Something Different

The barcode scans — the beep is there — but what lands in the field isn't what you encoded. There's an extra zero at the front, a Y where a Z should be, every letter in the wrong case, or the form submits before you're ready. Almost every one of these comes from one of seven causes. They fall into two groups: either the barcode really encodes something other than what you typed, or the barcode is fine and the trouble is in how the scanner types it into your computer.

The first test: is it the barcode or the scanner?

Scan the same barcode with a phone camera app that shows the decoded text. If the phone shows the right value, the barcode is correct, and the problem is somewhere between your scanner and the program receiving the text (causes 3 to 7 below). If the phone shows the wrong value too, the barcode itself encodes the wrong data, so look at how it was generated (cause 1) or at how the data was prepared before it was encoded (cause 2).

1. An extra leading zero: Code 128 set C with an odd number of digits

Code 128 has three character sets. Set C is the compact one: each symbol holds a pair of digits, which is why long numbers come out much narrower in it. The consequence is that set C can't hold an odd number of digits. Some generators, when told to use set C for a 7-digit number such as 1234567, quietly put a zero in front to make an even count. They encode 01234567, and that is exactly what every scanner then reads back. Barcode-font vendors document this behavior in their own support pages. Nothing is broken; the generator encoded different data than you gave it.

The fix is to let the generator choose the sets ("auto" mode). An auto encoder puts as many digit pairs as it can in set C and encodes the leftover digit in another set, so the barcode reads back exactly 1234567, and it is still nearly as compact. Force set C only when a specification requires it, and then make the data even-length yourself, deciding deliberately whether a leading zero is acceptable to the system reading it. FreeToolDev's bulk Code 128 generator uses auto by default, and when you force Code 128 C it rejects odd-length numbers with that reason instead of padding them silently.

2. Leading zeros vanish or numbers turn into 1.23E+12, but only in Excel

If the phone app shows 0036000291452 but the cell shows 36000291452, or a 13-digit EAN like 4006381333931 shows up as 4.00638E+12, the scanner did its job. Excel received the digits and decided they were a number. Numbers don't have leading zeros, and in the default General format Excel displays any number longer than 11 digits in scientific notation. Beyond 15 digits it goes further and replaces the trailing digits with zeros, and that loss can't be undone. Format the column as Text before you scan into it. Why Excel mangles long numbers covers the details. The same damage happens in reverse when barcode numbers are copied out of a spreadsheet into a generator, which is why ours flags codes that look like they lost a zero or were turned into scientific notation.

3. Letters or symbols swapped: the keyboard layout doesn't match

Most USB and Bluetooth scanners act as a keyboard (a "keyboard wedge"): they don't send the text, they press keys. A scanner set to a US layout that wants to type Z presses the key that is Z on a US keyboard. On a German QWERTZ computer that same key is Y, so Z and Y come out swapped. On a French AZERTY computer the digit keys produce & é " ' ( unless Shift is held, so a barcode full of numbers can arrive as punctuation. A US-versus-UK mismatch shows up in symbols such as @, " and #. The barcode is fine, and so is the scanner. They just disagree about which key is which.

The fix is to set the scanner's keyboard or country layout to match the computer. Scanner manuals almost always include a page of configuration barcodes for this. Alternatively, switch the computer's input language to the one the scanner assumes. To catch the problem in seconds, make one test label that contains YZyz@-1234567890 and scan it into a text editor.

4. Every letter in the wrong case: Caps Lock

Because a wedge scanner types like a keyboard, it uses Shift for capital letters. If Caps Lock is on, those Shift presses turn capitals into lower case and lower case into capitals. SKU-ab12 arrives as sku-AB12. Digits and most symbols aren't affected, which is why the problem can go unnoticed until a lookup suddenly fails. Turn Caps Lock off, or look in the scanner's configuration guide for a Caps Lock setting. Many models can be told to ignore Caps Lock or to detect it and compensate.

5. Extra characters before or after: Enter, Tab, prefixes and identifiers

Out of the box, most scanners press Enter after every scan. That suffix is what makes a point-of-sale lookup fire immediately and what makes Excel jump to the next row. It's also what submits a web form halfway through filling it in. Some are set to send Tab instead. Scanners can also add a prefix, and one common option is the AIM symbology identifier, a three-character tag such as ]C0 (Code 128) or ]E0 (EAN/UPC) placed in front of the data. If you see those characters, or an unexpected line break, they come from the scanner's configuration, not from the barcode. Remove or change them with the configuration barcodes in the manual.

One character you will never see is Code 128's own check symbol. Every Code 128 barcode contains a check character calculated with modulo 103, but the scanner uses it to verify the read and then drops it. Don't expect it in the output, and don't add one to your data yourself.

6. GS1-128 labels: missing parentheses and an invisible separator

On a GS1-128 shipping label (the format often still called EAN-128) the human-readable line shows Application Identifiers in parentheses, such as (01)09501101530003(17)271231. The parentheses are not in the barcode, so the scan arrives as 0109501101530003171231. The special FNC1 character that marks the barcode as GS1 at the start isn't transmitted either. Where a variable-length field (a lot number, say) is followed by another field, the separating FNC1 arrives as an invisible ASCII "group separator" character (code 29). Depending on the program, that shows up as nothing at all, as a strange box, or as a broken input. Systems that receive GS1 data are built to parse this. A plain text field isn't.

7. Characters missing or out of order

A long Code 128 value that sometimes arrives with a character missing or two characters swapped is usually a speed problem. The scanner "types" faster than the receiving program can accept keystrokes, which happens most with Bluetooth scanners, remote desktop sessions and slow web apps. Scanners have an inter-character delay setting that slows the typing down. It's a workaround rather than a cure, and the robust fix is software that receives the scan directly instead of as simulated keystrokes. If it never happens with a short code and only sometimes with a long one, this is almost certainly the cause.

A one-minute diagnosis

1. Scan with a phone app. Wrong there too? It's the barcode: check for set C padding (cause 1) or for data that was damaged before encoding (cause 2).
2. Right on the phone, wrong on the computer? Scan into a plain text editor, not the application. Wrong in the editor too? Then it's the layout (3), Caps Lock (4), the prefix and suffix settings (5), or timing (7).
3. Right in the editor, wrong in the application? The application changed it: Excel's number conversion (2), or a field that can't handle the GS1 separator (6).

For the tests, generate a few labels with the bulk barcode generator. Make one with your real data, one with an odd-length number, and the YZyz@-1234567890 layout test. Use Print sheet to get them all on one page. For the bigger question of which format a label should use in the first place, see UPC vs EAN vs Code128.