How to Scan a Barcode With Your Phone (UPC, Code 128, QR)

QR codes: the built-in camera is enough

Both major phone makers document QR scanning in their stock camera apps. On an iPhone, Apple's instructions say to open the Camera app, hold the phone so the QR code appears in the frame, and tap the link that shows up. Apple's iPhone User Guide adds that the Camera should be in Photo mode, and that you can instead tap the Scan Code control in Control Center once you've added it there. Apple's guide says to use the flashlight in that scanner when the light is poor.

On a Pixel, Google's help page says to open Camera, make sure Camera scan suggestions is turned on in the settings, and point it at the code with the whole code visible. You don't need to take a photo. Google says the camera shows a bubble or link, and you tap it. Other Android phones may differ, so check your phone maker's documentation; the sources here don't cover them.

In both cases the phone shows a link or bubble, and nothing opens until you tap it. Check where it points first. A QR code is just a way of writing text, so the same scan that opens your menu page could open any other address.

If you're making the code yourself, build it in the QR code generator, print a proof at final size and scan it with the camera app before you print a batch.

UPC, EAN and Code 128: use a scanner app

Apple's and Google's instructions above describe QR codes. Neither says the stock camera reads UPC or Code 128, so don't count on it. For linear barcodes, install a scanner app and look at which formats it lists.

Some apps are built on scanning libraries such as Google's ML Kit reads Codabar, Code 39, Code 93, Code 128, EAN-8, EAN-13, ITF, UPC-A and UPC-E, plus Aztec, Data Matrix, PDF417 and QR Code, on the device with no network connection. Apple's Vision framework lists a similar set, including Code 128, EAN-13, ITF-14, UPC-E and QR. Both libraries list Code 128, EAN-13 and QR, so an app built on either should read those. Apple's list has no separate UPC-A entry, so check that your app reads UPC-A; it may report it as EAN-13. An app that doesn't list a format can't be expected to read it.

Libraries have limits too. ML Kit says it doesn't recognize 1D barcodes with only one character, ITF barcodes shorter than six characters, or codes using the FNC2, FNC3 or FNC4 characters. It also calls ITF flaky because that format has no checksum.

What the result on screen means

A scanner app decodes the bars into text, and that text is all it knows. It doesn't know what the number means.

GS1 US says a GTIN in a UPC isn't automatically linked to the barcode-scanning apps on the internet, and GS1 US doesn't provide one (GS1 US FAQ). So "product not found" doesn't mean your number is wrong. Some apps look numbers up in their own databases, and that is different from checking who licensed the number (see how to check who owns a UPC).

Judge the raw digits instead. Say you print this UPC-A for a product: 614141234561. It has 11 data digits plus a check digit. Odd positions add up to 6 + 4 + 4 + 2 + 4 + 6 = 26, and 26 × 3 = 78. Even positions add up to 1 + 1 + 1 + 3 + 5 = 11. The total is 89, and the check digit that brings it to a multiple of 10 is 1, which matches. If the digits differ in more than an added leading zero, something is wrong with the number you encoded or the print. The check digit calculator does this math for any GTIN.

Expect small display differences. An app might show a UPC-A with a 0 added in front, because a 12-digit UPC-A is read as a 13-digit EAN-13 with a leading zero added; UPC vs EAN explains this. It may also leave out the dashes, parentheses or spaces you printed under the bars.

Why a phone scan doesn't prove the label works

A phone read passing doesn't prove a checkout or warehouse scanner will pass. They see the label differently.

GS1's 2D colour and quality guide says phones use broadband white light, while laser and imaging checkout scanners typically use red light in the 630 to 680 nanometer range. It also says a phone's larger aperture, 1.875 to 2.5 mm against the 0.30 mm used to verify 2D codes at retail, makes it less sensitive to low contrast. GS1's example is a red QR code that a phone can decode but a point-of-sale scanner may not.

The opposite problem exists too. In practice a phone camera can be forgiving about angle and distance, so a label that's slightly too small, has a narrow quiet zone or is printed with slightly fat bars may read fine and still be marginal. Measuring that margin takes a verifier; see barcode verification grades.

A practical phone test

Use the phone for quick checks, and do them on paper, not on a monitor.

1. Scan the printout, not the screen. The printer changes the bar widths and contrast, and that's the part you're testing.
2. Test at the final size. If the label is 25 mm wide, don't scan a full-page proof.
3. Scan from the distance a worker would. Hold the phone at arm's length for a shelf label, and closer for a small tag.
4. Try a bad case. Scan at an angle, in dim light and from a curved surface if the label goes on one.
5. Compare the digits to your source. Check the decoded text against the number you typed.
6. Repeat with the real scanner. Try the actual scanner at the register or on the dock before you print all the labels.

If a scan fails, work through the barcode not scanning checklist. A failure on the phone usually points at the print or the data, and the checklist starts with those.

Bottom line

For QR codes, open the camera and tap the link. For UPC, EAN and Code 128, pick a scanner app that lists the formats you use. Read the decoded digits, don't trust an app's product lookup, and treat a phone read as a first check. A label isn't ready until the scanners that will actually read it have read it. For how those scanners differ, see how barcode scanners work.