Text & everyday tools · QR & Barcode Toolkit
Code 128 vs Code 39 vs EAN-13: which barcode symbology to use
· Background
encoding file-formats printing
Compares the common one-dimensional symbologies on character set, density, check digits and scanner support, and explains why Code 128 is the usual answer for general-purpose labels.
Three barcodes that look alike and behave differently — why the symbology decision is made before any label is printed
Linear symbols can look interchangeable while carrying different validation rules and downstream expectations. The first decision therefore comes from the accepting scanner, retailer or internal system, not from which bars look best on a label.
The accepting system should name the symbology in writing. A scanner that can decode several formats does not make them interchangeable: the application may validate length, check characters or registered numbers after the optical read. Before printing, scan a representative label into the final software and confirm the returned value and acceptance result. ToolAcre only covers the branch where plain Code 128 is the specified input.
Code 39 is background only; ToolAcre does not generate or validate it
Code 39 is named in the comparison outline, but no ToolAcre config, implementation or test generates it. Its detailed repertoire and history are not established by these sources, so treat it as a separate candidate requiring independent documentation.
Because Code 39 is not imported, configured or tested, this article cannot verify its character repertoire, width or checksum behaviour. That is a deliberate content boundary, not a judgment about the format. If a legacy process names Code 39, use current documentation and a Code 39 generator with conformance tests. Producing Code 128 because it “looks similar” creates a label the legacy reader may ignore.
Code 128 is the only linear barcode implemented by the QR & Barcode Toolkit
ToolAcre implements plain Code 128 through CODE128_AUTO, accepts ASCII values, switches code sets automatically and appends a modulo 103 check symbol. That verified scope makes it useful for compact identifiers in systems you control.
The supported path has concrete safeguards: empty values are rejected, characters above ASCII 127 are listed in an error, CODE128_AUTO chooses sets, and the returned pattern is checked for validity. SVG and canvas render the binary with ten-module side margins. These behaviours make ToolAcre predictable for internal identifiers; they do not grant support for another format selected in a dropdown that does not exist.
EAN-13 and UPC-A are outside ToolAcre’s implemented and configured output
EAN-13 and UPC-A are not options in the application, and the configuration warns that registered product-number formats are deliberately excluded. Do not type a retail number into Code 128 and assume the resulting bars satisfy a retailer’s requirement.
Retail numbers require more than drawing thirteen digits in bars. ToolAcre explicitly excludes EAN and UPC and does not allocate or validate registered product identifiers. If a retailer requests one, obtain the number and artwork through the required process. Encoding those digits as Code 128 returns the same visible text on a scanner but the wrong symbology, so optical success can conceal business rejection.
Interleaved 2 of 5 and ITF-14 are background only and are not generated here
Interleaved 2 of 5 and ITF-14 are likewise outside the codebase. Their presence in a background outline does not confer support, and this article omits unverified technical comparisons instead of manufacturing a broad symbology table.
The same rule applies to ITF and ITF-14. They are not dependency options hidden behind the interface, and no test asserts their patterns. This article therefore avoids a feature comparison assembled from memory. A carton specification naming ITF-14 should be followed with a validated tool and print process intended for that label, not approximated with ToolAcre’s available linear output.
Choose by external requirements first; ToolAcre is suitable only when plain Code 128 is accepted
For internal assets, confirm that every scanner and application accepts plain Code 128 and the exact ASCII identifier. For shipping, retail or legacy workflows, obtain the required symbology specification first and use a generator validated for it.
For internal assets, run a closed-loop trial with the actual scanner, software and longest identifier. For a retailer or carrier, request the label specification and validation procedure before choosing software. For legacy documents, preserve the mandated format even when another seems denser. “General purpose” means useful when requirements permit Code 128, not a universal replacement for every linear barcode.
What this does not cover — two-dimensional codes, which get their own comparison
Two-dimensional formats are a different decision involving payload shape, available area and readers. ToolAcre offers standard QR separately, but it does not use that feature to imply support for Data Matrix, Aztec or stacked barcodes.
QR is available as a separate two-dimensional generator, but switching dimensions changes the reader requirement and payload conventions. ToolAcre does not offer Data Matrix, Aztec or PDF417. If a document standard mandates one, QR is not an equivalent fallback. The appropriate decision remains written requirement first, supported encoder second, and physical validation with the intended reader third.
The takeaway — for labels you control, Code 128 is the sensible choice, and the QR & Barcode Toolkit generates it in your browser
Choose the required standard before generating artwork. When the requirement is ordinary Code 128, ToolAcre supplies local SVG and PNG output; when it names another symbology, this toolkit is plainly not the producer to use.
When Code 128 is accepted, keep the data ASCII, preserve margins and test the extreme labels before locking a template. When another name appears in the requirement, stop rather than searching this UI for a workaround. A clear refusal is cheaper than printing a plausible symbol that decodes in an office test but fails at checkout, goods-in or a regulated handoff.