Azalea Software, Inc.

Which Bar Code Do I Need?

There are different types of bar codes, called symbologies. While most scanners read almost all bar code symbologies, the choice of which bar code symbology to use is often dictated by your specific application, and/or requirements and specifications imposed by business partners. In other cases, the nature of the data being encoded eliminates some symbologies if not mandating others.

When faced with the prospect of creating bar codes for the first time many people are confused by the many different bar code symbologies. Each symbology, or bar code dialect, employs different patterns of bars and stripes.

While most scanners read most types of bar codes, in the end the choice of which symbology to use is usually not up to the end user. Either the environment the bar codes will be used in mandates A over B, one's trading partners expect one over another, or you're required to adhere to a specification which specifies exactly which bar code to use (often along with what size and shape and other details as well).

The one exception to the "Scanners Don't Care Rule" is that most scanners, especially older or less expensive ones, can only read 1D (one dimensional) bar codes like Code 128, Code 39, UPC, etc. Newer 2D (2 dimensional) symbologies like PDF 417, Data Matrix, and MaxiCode require newer scanners. RTFM

The first question you have to ask is "Am I trying to recreate an existing bar code?" If so, then the decision isn't up to you. Your predecessor used Code 128, you're told to pick up where they left off, and guess what, you're going to use Code 128 too. You're updating a product's packaging and it includes an EAN-13 bar code because it's being sold in Europe. The distribution and retail channel demands EAN-13, so that's what you have to use.

Sometimes a bar code's purpose dictates which bar code symbology is being used. If you're putting bar codes on U.S. mail based on the ZIP code, then you're going to create POSTNET bar codes. That's what the U.S.P.S. mandates and that's what you need to do. If the bar codes are going on items destined to be scanned at a cash register in the U.S. or Canada, you need to make a UPC bar code. Not Interleaved 2 of 5 or Codabar or Code 39. You need to employ UPC symbols.

When implementing bar codes at the request of a business partner - supplier, distributor, reseller, etc. - that company probably knows what bar code they want you to use. Some companies can give you a written set of requirements. While these documents can sometimes be large and somewhat obtuse, they describe the acceptable bar code symbologies as well as symbol size, shape, location, etc. In other situations you're required to comply with an industry specification or standard. Read it carefully. When it mandates the use of a bar code, it will describe what kind, how big, and what needs to be in it.

What alphabet do you need to use? Is your input string numbers-only or do you need to encode letters too? Lowercase letters or uppercase letters with punctuation, control codes, and other misc. characters? And as a secondary consideration, how large or small can your bar code be? These questions narrow your choices down once you've eliminated POSTNET on mail or UPC on retail items.

If you'll be encoding numbers-only (or more importantly you don't need to use letters) then Interleaved 2 of 5 is a popular choice. It's relatively compact width-wise and is said to be strongly self-checking (the symbol's geometry and structure guards against mis-scans). Code 128 code set C is especially narrow and is part of many industry specifications. Other symbologies like Code 39 can be used too but it offers no advantage to a numbers-only situation.

If you'll be encoding letters, your choices don't include Interleaved 2 of 5. You should consider Code 39 and Code 128. Both symbologies' character sets include A-Z, 0-9, and several basic math punctuation marks. All scanners read both. The difference is twofold: Code 128 is smaller and its character set (alphabet) includes the letters A-Z, a-z, 0-9, and most of the typeable keyboard characters. In fact, its name comes from the fact that it can be used to encode the lower 128 ASCII characters.

Another consideration is how much data you need to store in your bar code. As mentioned above, some symbologies like Code 128 and Interleaved 2 of 5 are denser and store more data in a given space. Sometimes the amount of data you need to encode dictates what kind of bar code you need to create. 1D bar codes like UPC, Code 39, and Code 128 tend to be used as lookup numbers into external databases. The real data isn't necessarily in the bar code itself but scanning the bar code's unique string locates that data in a database. This is how scanning a box of cereal in the grocery store results in the cash register displaying not only the price but the product's name. A UPC bar code is merely a unique 11- digit number that matches a database entry describing that item. Think about it: if the bar code included information like the price then putting something on sale would require re-bar coding it and when the sale ended, you'd have to re-re-bar code it. The same holds true for raising or lowering a product's price. Yuck! It's much easier to change the database record and have the cash register bring up that revised price.

Sometimes on things like name badges or shipping labels the bar code includes all the data you need to manipulate. Things like the employee's name or a part number. If the snippet of data is small enough, then the bar code can be self-contained and something like Code 128 or Code 39 is adequate. In other scenarios you want to encode more data than can be put into a simple 1D bar code. 2D symbologies like PDF 417 and Data Matrix contain relatively large amounts of data. The bar code contains all the information you need access to. There's no need to refer to an external database.

The Bar Code Selection Rules of Thumb

If your bar code application specifies a certain symbology or your business partner(s) know which symbology you need to use, your choice is made for you.

The alphabet you need (numbers-only, letters, mixed alphanumeric, etc.) eliminates certain symbologies and/or leads you to consider others.

If your data changes more frequently than you're willing or able to regenerate the bar code then store the data in a database and use a bar code to look it up.

If the data is larger than the snippet a 1D symbology can encode, use a 2D symbology that does hold that much information.

If you're not connected to a database in real time either scan and store the bar code, processing it later when you are connected to a database, or store all you need in a 2D bar code so you can operate independent of a database.