QR Code vs Barcode: Which One Should You Use?

QR codes and barcodes look like cousins from a distance: both are printed patterns that machines read. They solve different problems. The barcode has been scanned at shop checkouts since 1974 and still runs retail, warehousing, and pharmacy. The QR code is a younger, denser format that reached the public through the smartphone camera.

Most teams asking "QR or barcode?" are really asking a different question: given my use case, who scans this thing, and what hardware will they have? The answer follows from there. A clerk at a grocery checkout has a scanner built into the counter, so the barcode wins. A diner at a restaurant table has a phone, so QR wins. A warehouse worker scanning pallets has a rugged handheld scanner, and there the barcode usually still wins, though 2D codes are gaining ground.

The deciding factors are data capacity, scanning hardware, error correction, and cost. For many products the answer is to print both.

A brief history: 1974 vs 1994

The first barcode scan at a checkout happened on June 26, 1974, in a Marsh supermarket in Ohio, when a pack of Wrigley's gum became the first product in the world to be scanned with a barcode, according to GS1's history of the barcode. The code was a Universal Product Code (U.P.C.), which is still the product identifier of North American retail. GS1 now counts over 1 billion products carrying its barcodes, scanned billions of times every day.

QR codes arrived twenty years later. Masahiro Hara, an engineer at Denso Wave (then a division of the Japanese car-parts maker Denso), led the team that released the format in 1994. The reason was capacity. By Denso Wave's account, a barcode "can only hold 20 alphanumeric characters or so," which meant printing and reading many of them. Hara's 2D code held far more data in the same space, and the three position detection patterns in its corners let scanners find and read it from any direction.

For years after that, QR codes were mostly an industrial format. That changed when phone cameras began reading them without an extra app. On the iPhone this came with iOS 11 in 2017, when Apple added system support to detect QR codes in Camera.

Data capacity: the 200x gap

A 1D barcode holds little. UPC-A, the format on grocery items in North America, holds exactly 12 numeric digits. Denso Wave's history puts a general-purpose barcode at about 20 alphanumeric characters. The bars run in a single dimension, so the only way to add capacity is to make the code wider.

QR codes encode in two dimensions. The largest QR code (Version 40) is a 177 x 177 module grid that stores up to 7,089 numerals, or 4,296 alphanumeric characters. The Japan Patent Office, in its account of the invention, puts the gain at about 200 times the information of a conventional 1D code. Almost no real-world QR code uses that ceiling, since most carry a short URL. The headroom is what lets a full vCard or a WiFi password fit in one code.

A Code 128 barcode can encode a URL such as https://example.com/product/12345, but it comes out as a long strip, and the strip grows with every character. The same string in a QR code stays square. If your data is a short number, the barcode is the more compact choice. For anything longer, QR is the format that fits on a small label.

Scanning hardware: the real decider

This is where most "QR vs barcode" arguments actually get decided. A 1D barcode is built for a 1D scanner: a laser line or linear imager that sweeps across the bars. Phones can read 1D barcodes inside some apps, but the stock camera app is set up for QR codes. A dedicated barcode scanner is an extra purchase for every station that needs one.

A QR code needs a 2D imager, and a smartphone camera is one. iPhones have read QR codes from the Camera app since iOS 11, and on Android, Google's own instructions are to open the camera app and point it at the code. In a consumer-facing setting the scanner costs you nothing, because it is already in the customer's pocket.

Everything else follows from that. Where the person scanning is an employee in a controlled environment (checkouts, warehouse pick-paths, library desks), barcodes can stay, because the scanners are already bought and in use all day. Where the person scanning is a member of the public (restaurant menus, event tickets, posters, asset stickers), it has to be a QR code, because nobody buys a scanner to look at your poster.

Error correction: Reed-Solomon vs nothing

A 1D barcode has little tolerance for damage. Formats like Code 128 and UPC-A carry a check digit that detects a bad read, but nothing that can rebuild missing data. If no clean line across the bars survives, the scanner fails and the cashier types the number by hand.

QR codes build Reed-Solomon error correction into the format. There are four levels: L (~7%), M (~15%), Q (~25%), and H (~30%). The level you pick sets what fraction of the code can be obscured, scratched, or covered while it still scans. A QR code at level H can carry a logo in the middle or take a scratch and still resolve. This is why QR codes with logos work at all: the logo covers part of the data area, and the error correction reconstructs the missing modules.

Where a label is likely to get dirty, weathered, or scuffed (outdoor signage, asset stickers in industrial settings, packaging in transit), that error correction is the reason to choose a QR code.

Cost: free phone scanner vs dedicated hardware

Generating either format costs next to nothing, and the printing cost per label is the same, since both are ink on paper. The cost difference is on the scanning side.

A dedicated barcode scanner has to be bought for every checkout, packing bench, and handheld user, and rugged warehouse units with a screen cost more than basic ones. Across a retail chain, the scanner fleet is a capital line of its own.

With a QR code, the public brings the scanner. The phone is already there and its camera app already reads the code. If you are asking the public to scan something, this settles it: you cannot print a barcode and expect passers-by to scan it. Where you control the scanner (employees, kiosks), a phone can also stand in for dedicated hardware.

When barcodes win

Barcodes are still the right tool for any high-volume, controlled-environment scanning use case where dedicated hardware is already deployed and the data being encoded is short and stable.

Point-of-sale checkout. A fixed scanner reading a UPC is fast and needs no aiming, so a trained cashier keeps items moving without looking for the label. Moving the SKU to a QR code gains nothing at the till unless the code also has to carry extra data.

Warehouse and supply chain. Pallet labels, pick-list tickets, and fast-moving inventory transactions favor 1D barcodes when the workforce is equipped with industrial scanners. The codes are small and quick to read, and the processes around them are mature.

Books, libraries, and ID systems. ISBN barcodes on books, library card numbers, and hospital wristbands are stable identifiers in environments with dedicated scanning infrastructure. There's no pressure to switch them to QR.

When QR codes win

QR codes win every consumer-facing scenario by default and most internal scenarios that involve mixed devices, dynamic content, or analytics.

Anything a stranger scans with a phone. Restaurant menus, marketing posters, event tickets, payment terminals, business-card details, WiFi passwords, real-estate yard signs. The phone is the scanner, and its camera reads QR codes without an extra app.

Anything that needs to change without reprinting. A dynamic QR code encodes a redirect URL on a service provider's domain. Change the destination from a dashboard, and every printed sticker points somewhere new. A printed barcode has no redirect behind it: the number on the label is the number that gets read.

Anything that needs scan analytics. Each scan of a dynamic QR code is logged with its time, an approximate location, and the device type. Barcodes have no analytics of their own. Whatever system scans the barcode owns the data, which works inside a closed checkout or warehouse system and is useless on a public sign.

Anything longer than a short identifier. URLs with query parameters, vCards, WiFi credentials, and deep links are all too long for a practical 1D barcode. A QR code holds them in a square footprint.

The hybrid strategy: use both

Many products carry a barcode and a QR code side by side, and for many deployments that is the right answer. The barcode handles the operational layer (the SKU at checkout, the inventory ID in the warehouse). The QR code handles the consumer layer (the product page, the warranty registration, the recall notice).

Look at the back of a food product and you'll often see two codes: a UPC-A barcode for the cashier to ring up, and a QR code that takes the buyer to nutritional details, sourcing information, or a campaign page. Shipping labels often carry more than one code for the same reason: different audiences use different scanners and need different amounts of detail.

The cost of printing both is essentially nothing. The benefit is that you stop having to choose between operational efficiency and consumer engagement.

Migration considerations: when to move from barcode to QR

If you're currently barcode-based and thinking about migrating, the migration doesn't have to be all-or-nothing. The cleanest path is to add QR codes to existing labels first. Keep the barcode for whatever scans it today, put a QR code alongside it, and retire the barcode only after every consuming system can read QR.

The realistic constraint is your scanner fleet. A retail operation that has just refreshed its checkouts with 1D-only scanners isn't going to junk them next quarter. The next fleet refresh can specify 2D imagers, which read both formats, and that's the natural moment to start phasing in QR. The same logic applies in warehouses: where the handhelds already read 2D codes, what's missing is the data model and the printing pipeline.

For consumer-facing labels there is no migration question: add a QR code. The barcode can stay or go without affecting the customer. Start with product packaging, inserts, manuals, and post-purchase touchpoints. See our write-up on how to create a QR code for the practical first steps.

FAQ

Are barcodes obsolete?

No. GS1, the body that administers retail barcodes, says its barcodes are on over 1 billion products and are scanned billions of times every day. They run point-of-sale checkouts, warehouse pick-paths, and library systems because they are small, quick to read, and long proven. QR codes have taken over consumer-facing and dynamic uses such as menus, payments, and marketing, while barcodes remain the norm in operational environments where dedicated scanners are already deployed. Expect the two to coexist.

Can a phone scan a barcode?

Yes, with the right app, but less conveniently than a QR code. Reading a 1D barcode on a phone usually means opening a shopping, inventory, or scanner app first. QR codes need no app: iPhones have read them from the Camera app since iOS 11 (2017), and Android phones scan them from the built-in camera app. That difference is the main reason QR codes are the format used for anything the public scans.

Which is faster to scan, QR or barcode?

At a checkout, the barcode. A dedicated scanner reads a clean barcode almost instantly, and a trained operator barely has to aim. A QR code read by a phone takes a moment longer, because the user has to open the camera and frame the code. For a one-off consumer scan that difference doesn't matter, and the QR code wins because the phone is already in the person's hand.

What about 2D barcodes like Data Matrix or Aztec?

Data Matrix, Aztec, and PDF417 are all 2D codes, close relatives of the QR code. Data Matrix is common where the mark has to be very small, such as on pharmaceutical packs and electronic components. Aztec is used on many rail and airline tickets, and PDF417 appears on US driver's licenses and some boarding passes. All three are capable formats. What they lack is the public recognition and stock-camera support that QR codes have, which is why QR is the default for any new public-facing application.