How to Evaluate Whether Your Printer Can Handle Serialized 2D Codes

Serializing a product means printing a different code on every unit, at production speed, and knowing that each one is right. Whether your existing equipment can do that is one of the first practical questions in any serialization project — and one of the most often answered by guesswork. This guide gives you the questions to ask and a way to test the answers.

If you are still deciding whether to serialize at all, read do all products need serialization? first. For the wider preparation picture, see the cornerstone GS1 2D readiness checklist for manufacturers.

Why serialized printing is different

Most lines already print something on each pack: a batch number, a best-before date, perhaps a price. That data changes once per run. Serialization changes three things at once:

1. The data changes for every unit. The coder must receive a new serial for each pack, in time, without skipping or repeating one.
2. The image is a 2D code, not text. A 2D barcode must be printed precisely enough for scanners and phones to read it, which is a higher bar than legible text.
3. Every unit must be confirmed. Because each code is unique, a missed or unreadable print is a lost identity, so the line must check each code and act on failures.

For background on what coders do and the main types, see what does an industrial coder do?

Print technologies in general terms

Each family of technology has typical strengths and limits. These are general tendencies, not product claims — individual models vary widely.

The right question is never "is this technology good enough?" but "can this machine print this code on this pack at this speed?"

The five things to assess

1. Resolution against code size

A 2D code is a grid of small squares (modules). The printer must place each module cleanly, with sharp edges and no bleeding into its neighbours.

• What resolution does the printer achieve on your material, not on test paper?
• What is the smallest module size it prints reliably? For general retail, GS1 sets a 2D module size (X-dimension) range of 0.396–0.990 mm, aiming at 0.495 mm.
• How large does the code become with your actual data? A long Digital Link plus a 20-character serial needs more modules than a GTIN alone.
• Is there room on the pack for the code plus its quiet zone — the empty margin around it (4 modules for a QR code, 1 for a Data Matrix)?

2. Substrate

The same printer can produce an excellent code on uncoated board and a poor one on varnished film.

• What exactly will the code be printed on: board, label, film, glass, metal, a curved or textured surface?
• Does the ink or mark adhere, dry in time before the next contact point, and survive handling, condensation or abrasion?
• Is the contrast between the code and the background high enough? Dark codes on light backgrounds read best; printing onto metallic or patterned areas is a common failure.

3. Line speed and timing

• What is your fastest line speed for the products concerned, in units per minute?
• How much time does the printer have per unit, and does that include receiving the next serial?
• What happens when the line accelerates, stops and restarts, or when products are irregularly spaced?

4. Data rate and the variable-data interface

This is where many serialization projects stall. The printer must be fed unique data quickly and reliably.

• How does the printer receive variable data — over a network protocol, through a vendor's software, through a line controller?
• Can it buffer a queue of upcoming serials, and confirm which ones were printed?
• What does it report when a print fails, the queue empties or a fault occurs?
• If the connection to the data source drops, does it stop safely, or could it repeat the last code?

Repeating a serial is worse than missing one: two packs with the same identity create a false duplicate in the market. Integration questions like these are covered in how ERP, printer, scanner and packaging line work together.

5. Read-back and rejection

A printer acknowledging a print tells you it attempted to print. It does not tell you the code is on the pack, readable and correct.

• Is there a camera or reader after the printer to read every code?
• Does it compare what it read against the serial that was sent?
• Can the line reject a failed unit automatically, and is the reject confirmed?
• Separately, for formal verification, will samples be graded with an ISO-conformant verifier against ISO/IEC 15415, to check print quality — the 1.5 (C) minimum for retail codes — not just readability?

Ask for a trial

Specification sheets describe ideal conditions. Your line is not ideal. Before committing, run a structured trial.

1. Use your real packs — the actual material, coating and print position.
2. Use real data — serialized codes of the length and format you will use, not a repeated test code.
3. Run at production speed, including your fastest product and normal starts and stops.
4. Run long enough to see drift: many problems only appear after the printhead warms up or ink levels change.
5. Read back every unit and count no-reads, misreads and duplicates.
6. Grade samples from the start, middle and end of the run with a verifier.
7. Agree pass criteria in advance: minimum grade, maximum reject rate, no duplicates, no missing serials.

Record the results so they can be repeated when the line, material or printer changes.

A worked example

Volta Cables, a fictional manufacturer, wants to print a serialized QR code on the side of each cable-coil box. Its line already has an inkjet coder printing the batch and date.

In a trial, the coder prints readable codes at slow speed. At full speed, the camera after the coder flags a rising number of no-reads as boxes with a glossy patch pass the print head. Moving the print position to a matte area fixes the readability. A second issue appears: when the network connection to the data source is briefly interrupted, the coder repeats its last code. Volta's integrator changes the configuration so the line stops when the queue empties — a far smaller problem than duplicate serials in the market.

None of this was visible on the coder's specification sheet.