Barcode Generator: How to Pick the Right Format and Test the Output

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

A barcode generator renders a typed value into one symbology's bars and spaces; it does not choose the correct format, verify that a number was ever allocated, or guarantee a printed copy will scan. Match the symbology to the receiving system, enter a value that passes its length and character rules, then test the exported file before production.

What a barcode generator actually renders

A barcode generator is a rendering step, not a decision-making one. It takes the value you type, applies the encoding table of the symbology you selected — which bar and space widths stand for which character — and draws vector or raster output. For a retail format such as EAN-13 or UPC-A, that rendering step also recalculates a check digit from the digits supplied, which is a genuine service: it catches many transcription mistakes before printing. What it cannot do is confirm that the number was ever assigned to a real product, that a Code 128 string matches an internal database key, or that the printed copy will actually be legible at the size a scanner needs. A symbol that renders without an error message is evidence that the bars satisfy the format's geometry; it is not evidence that the underlying value is correct, owned, or ready for the workflow it is meant to serve.

Match the symbology to the scanner that will read it

Choose the symbology from the receiving application, not from which pattern looks the most professional. A point-of-sale lane expects an allocated GTIN in EAN-13 or UPC-A. An outer shipping case commonly carries ITF-14. An internal asset tag or work order can use Code 128, which accepts the full ASCII range and often gives the most compact result for a mixed alphanumeric string, or Code 39, which is restricted to uppercase letters, digits, and a small punctuation set but remains supported by some legacy readers that do not handle Code 128. A supply-chain label that must carry a date, lot, or serial number alongside a GTIN needs GS1-128, not a plain Code 128 string. Picking a format because a generator's default tab happened to be open is how a warehouse ends up with a technically valid symbol its own receiving software cannot parse.

Worked example: entering a twelve-digit value for a retail symbol

Take the twelve-digit body 400638133393, the kind of value a retail-symbol generator expects for EAN-13. Entering only the twelve digits should produce a complete thirteen-digit symbol, because the tool calculates and appends the missing check digit rather than requiring you to compute it by hand. After rendering, the generator reads its own output back — decoding the drawn bars locally — and reports the exact digit string it produced, including the calculated check digit. If that read-back string does not match what you expected, stop before printing: a mismatch usually means the wrong number of digits was entered, or a leading zero was dropped when the value was copied from a spreadsheet that stores it as a number instead of text. The read-back step is a local sanity check on the rendering, not a claim that this body belongs to an allocated GTIN for any real product.

Why a generator rejects a value that looks fine

A barcode generator refuses input for reasons specific to the symbology, and the message can look unhelpful if you do not know the rule behind it. EAN-13 and UPC-A fields only accept digits, so a value copied with a trailing space or a stray hyphen is rejected outright. Code 39 is restricted to uppercase letters, digits, a space, and the characters - . $ / + %; a lowercase part number typed straight from an inventory system will fail until it is converted to upper case. Code 128 accepts a much wider range of printable text, so a rejection there usually means a non-printable or control character slipped in during a copy-paste from a formatted document. None of these refusals are the generator being overly strict for its own sake — they enforce the same constraints a real scanner and its receiving software will apply, just earlier and more cheaply than a failed shipment.

SVG or PNG: which export survives a print shop

Vector output (SVG) preserves the exact bar and space widths at any print size, because it stores the geometry as instructions rather than as a grid of pixels. Raster output (PNG) fixes a resolution the moment it is generated, and enlarging it later — or letting a layout application scale it non-uniformly — can blur or distort narrow bars below the width a scanner's optics can resolve. For anything going to a professional printer, export the vector file and place it without stretching one axis independently of the other. If a workflow genuinely needs a raster file, generate it at the final physical size and resolution rather than exporting once and resizing repeatedly in a page-layout tool, since each resize is a fresh chance to compress the narrowest element below its minimum width.

Mistakes that happen after a valid symbol is generated

The most common mistake is not a rendering failure but a workflow one: a correctly generated symbol is placed on artwork after the proof was approved, without a fresh check. A second is exporting the symbol at draft resolution for a quick internal review and then sending that same file to the print supplier, skipping the higher-resolution export the process actually needs. A third is regenerating a batch of labels from a spreadsheet where one row has an extra digit or a text-formatted number with a dropped leading zero, and not spot-checking the read-back result before the whole run prints. Each of these produces a symbol that decoded correctly at the moment it was made and then failed somewhere between the generator and the shelf, counter, or loading dock.

What a generator cannot decide for you

A barcode generator cannot certify print quality the way a dedicated verifier can. ISO/IEC 15416 defines the methodology for measuring and grading a printed linear symbol's quality, evaluating attributes across multiple scan lines to produce an overall assessment; that standard applies to a physical, printed symbol read by linear scanning methods, not to a screen preview or a single successful local read-back. A generator's own decode check only proves that the file it just drew can be decoded from that same file — it says nothing about contrast, edge sharpness, or quiet-zone integrity once the design reaches ink, thermal transfer, or a label printer. For a label where a failed scan is expensive, treat the generator's output as a draft to be verified on the real substrate and reader, not as a finished, certified symbol.

Keeping a generator record for a reprint six months later

A label ordered again after a stock run-out, a packaging refresh, or a supplier change is a common source of a barcode quietly changing without anyone deciding it should. If the only record of a symbol is the printed carton on a shelf, a reprint has to reverse-engineer the original value by photographing and decoding an existing box, which works until the last physical copy is gone or damaged beyond reading. Keep the source string, the symbology, the generator settings, and the confirmed read-back result in a small file alongside the design artwork itself, not only in the memory of whoever set it up originally. When a reprint request arrives months later, that record answers the only question that matters — is this the same encoded value as before — in seconds instead of by comparing a new export against a physical sample and hoping nothing was typed differently the second time. Version the record itself, too: note the date it was last confirmed against a physical proof, and treat a record older than the most recent packaging or artwork revision as unverified rather than assumed current. A generator's own settings — error-correction level for a 2D symbol, the checksum option chosen for Code 39, or the resolution used for a raster export — belong in that same record, because two exports built from identical source text can still differ physically if a setting changed between them without anyone deliberately deciding it should. Teams that keep this record inside the same folder as the approved artwork, rather than in a separate spreadsheet nobody remembers to update, tend to catch a stale reprint before it reaches a supplier rather than after a customer reports a failed scan at the till. ISO/IEC 15416 Bar Code Print Quality Test Specification is the named source for the current external rule or product behaviour.