Which barcode types can a phone camera actually scan?

Modern phone cameras reliably decode thirteen symbologies on both iOS and Android: the 1D codes EAN-13, EAN-8, UPC-A, UPC-E, Code 128, Code 39, Code 93, Codabar, and ITF-14, plus the 2D codes QR, Data Matrix, PDF417, and Aztec. That list matches what Expo's camera module and Google's ML Kit both document, and what Apple's own AVFoundation barcode detection supports on iOS.

How reliable is barcode scanning with a phone camera compared to a dedicated scanner?

For spot checks, receiving, and small-team inventory, a phone camera is reliable as long as the barcode is well lit, in focus, and fills a reasonable part of the frame. Apple's own guidance notes that only one 1D barcode is decoded per frame, centered in the scan region, so a shelf of tightly packed codes gets read one at a time rather than in a sweep. A dedicated laser or imager scanner is still faster for high-volume, all-day warehouse picking, but for most small and mid-size operations a phone is the cheaper and simpler choice.

Can I scan receipts into Excel instead of barcodes?

Yes, but it's a different job. A receipt usually doesn't carry a barcode for the purchase itself, so reading one means text extraction (OCR) from a photo, not decoding a symbology. Both start with the same phone camera capture, though, and both can log a row to the same spreadsheet, which is why scan receipts to Excel app and scan barcode to Excel app often end up as two modes of the same tool: expense capture on one side, inventory or asset capture on the other.

How does the scanned data end up in a spreadsheet I can open in Excel?

The app stores every scan as a row in a database as it happens, then exports that table as a spreadsheet file, or syncs it to one automatically. In Newly, camera access and a database are both native building blocks, so this workflow doesn't need a separate barcode SDK bolted on; it's just an app that logs scans to rows, and rows to a sheet.

Do I need Wi-Fi or a data connection to scan barcodes?

No. Decoding happens entirely on the device, so scanning works with no signal at all, which matters in a warehouse corner or a truck bay. A connection is only needed to push the log to a shared spreadsheet or teammate; most apps queue scans offline and sync them once a connection comes back.

Articles · App ExamplesPublished July 2026

Scan barcode to Excel app:
the real build guide.

If you searched scan barcode to Excel app, the actual problem is usually simple: get barcode data off a shelf, a delivery, or a stack of paperwork and into a spreadsheet without retyping it. This guide covers which barcode symbologies a phone camera can really read, how a scan turns into a spreadsheet row, and where a barcode scanner to Excel app is worth building instead of buying off the shelf.

If the scanning workflow is really one piece of a larger tool your team needs, see internal business apps for the wider playbook.

See what a phone camera can read

The short version

A camera, a row, a spreadsheet.

A scan to Excel app has three parts, and none of them are exotic. The phone camera decodes the barcode. The app writes the result as a row, with whatever extra fields your workflow needs. The log of rows exports as a spreadsheet, or syncs to one automatically. The interesting part isn’t the barcode decoding — phones have been reliable at that for years — it is deciding what a scan should record beyond the code itself, and where the spreadsheet lives once it exists.

What a camera can read

Which barcode types a phone camera actually decodes.

Thirteen symbologies show up consistently across the documentation for iOS and Android camera scanning: nine one-dimensional (1D) codes and four two-dimensional (2D) codes. That list is remarkably consistent between platforms — Apple’s native camera framework, Google’s ML Kit, and Expo’s cross-platform camera module all land on close to the same set.

1D codes: the retail and logistics workhorses

One-dimensional codes are the classic striped barcode — EAN-13 and UPC-A on retail packaging, Code 128 on shipping labels, Code 39 on older industrial tags. They read reliably, but only one decodes per camera frame on iOS, centered in the scan area, so the code needs to be reasonably sized and in focus rather than tiny and far away.

2D codes: QR, Data Matrix, PDF417, and Aztec

Two-dimensional codes pack data into a square or stacked pattern instead of a line of stripes. QR is the one everyone recognizes; Data Matrix shows up on small parts and pharma packaging where there isn’t room for a wide 1D code; PDF417 is on driver’s licenses and shipping labels; Aztec is common on airline boarding passes. All four tend to scan faster than 1D codes because they tolerate more angle and a wider range of distances.

Try it — pick a symbology

QR Code

Typically used for: Menus, URLs, quick logging, asset tags

Scanning tip: The most forgiving code to scan — reads from an angle and across a wide range of distances.

Reliable on iOS and Android live camera scanning

All thirteen, at a glance

Symbology	Type	Typically used for	Scanning tip
QR Code	2D	Menus, URLs, quick logging, asset tags	The most forgiving code to scan — reads from an angle and across a wide range of distances.
Data Matrix	2D	Small parts, medical and pharma serials, PCB labels	Reads well even printed tiny, since it packs data densely into a small square.
PDF417	2D	Driver's licenses, boarding passes, shipping labels	Really several 1D rows stacked, so hold the phone steady — motion blur costs more accuracy here.
Aztec	2D	Airline boarding passes, event tickets	Needs no quiet-zone border, so it tolerates a tighter crop than most 2D codes.
EAN-13	1D	Retail products sold outside the US and Canada	Fill a good portion of the frame — only one 1D code decodes per frame on iOS.
EAN-8	1D	Small retail packaging with limited label space	Same read behavior as EAN-13, just a shorter code.
UPC-A	1D	Retail products sold in the US and Canada	The barcode most people picture — dependable under normal store lighting.
UPC-E	1D	Compact retail packaging (a compressed UPC-A)	Decodes down to the same UPC-A data, just printed smaller.
Code 128	1D	Shipping, logistics, asset tags — the basis of GS1-128	Encodes letters and numbers, not just digits, so it shows up on most internal asset labels.
Code 39	1D	Industrial, government, and automotive labeling	An older, wider format — give it more frame space than Code 128.
Code 93	1D	Logistics labels that need a denser Code 39	Packs more data per inch than Code 39 at similar reliability.
Codabar	1D	Libraries, blood banks, older logistics systems	Still common on legacy tags — reads like any other 1D code.
ITF-14	1D	Case- and carton-level shipping labels	Needs six or more digits to decode reliably — it has no checksum below that.

Sources: Expo Camera documentation, Google ML Kit barcode scanning, and Apple Technical Note TN2325.

Phone vs. dedicated scanner

Do you even need a scanner gun?

For a lot of teams searching for a barcode scan to Excel app, the honest question underneath is whether a phone is good enough, or whether the job needs dedicated hardware. Usually it comes down to volume.

	Phone camera app	Dedicated scanner
Upfront cost	None — uses the phone your team already carries	$200–$1,500+ per handheld unit, plus a charging dock
Best for	Spot checks, receiving, audits, small-team inventory	High-volume, all-day picking in a fixed warehouse
Setup	Install an app, grant camera permission	Pair the device, configure the middleware, train staff
Offline scanning	Yes — decoding is entirely on-device	Yes, with a sync step once back in range
Extra fields per scan	Whatever the app asks for — quantity, condition, location	Limited to what the scanner's own keypad or app supports
Rolling out to a new hire	Hand them a phone; most people already know how to use one	Issue a unit, charge it, train the device-specific workflow

If the workflow is squarely warehouse picking at volume, a barcode scanning app for inventory is worth reading on its own — inventory has different accuracy and speed tradeoffs than a general scan-to-spreadsheet tool.

Try it

How much time would scanning save you?

A rough estimate, not a promise — pick roughly how many rows your team logs a day and see the gap between typing each one in by hand and scanning it.

Rows logged per day

Typing each row by hand

30 min/day

Scanning each row

8 min/day

Time saved

~8 hrs/month

Assumes about 12 seconds to find, key in, and double-check a row by hand, versus about 3 seconds to point, scan, and confirm, over a 22-day working month. Slower typists and messier source data widen the gap; simple, well-lit codes narrow it.

The flow

From scan to spreadsheet row.

Four steps take a barcode from a shelf to a cell in Excel. We won’t go deep on the native camera implementation here — see using the camera for scanning for how camera permissions and live preview actually get wired into a mobile app.

1
The camera decodes the code, on-device
The phone's camera looks for a symbology it recognizes in the live preview and decodes it locally — no network call, no cloud lookup. This is why scanning still works with no signal.
2
The app writes one row
A successful scan becomes a row: the code's value, which symbology it was, a timestamp, and whatever else the workflow needs — quantity, location, condition, whoever is signed in.
3
Rows land in a database, not just a screen
Instead of only showing the result on screen, the row is saved, so ten people scanning from ten phones all write into the same running log rather than ten separate lists.
4
The log becomes a spreadsheet
Export the log as a CSV or XLSX file whenever you need it, or sync it automatically to a shared sheet. Either way, Excel opens the same table your team scanned into all day.

Starting from an existing spreadsheet rather than a blank one? Newly's guide to converting the spreadsheet itself into an app covers how to turn a sheet your team already relies on into the structure a scanning app writes back into.

Not the same job

Scanning a barcode is not scanning a receipt.

A lot of people searching for a scan to Excel app actually mean receipts, not barcodes. A retail receipt usually doesn’t carry a barcode for the purchase total — reading one means extracting the printed text from a photo (optical character recognition, or OCR), which is a different technique from decoding a symbology, even though both start with the same tap of the shutter.

In practice, a scan receipts to Excel app is an expense-capture tool: photograph the receipt, pull out the vendor, date, and total, and write that as a row. A barcode scanner to Excel app is an inventory or asset-tracking tool: decode a code, write the item and quantity as a row. They can live in the same app as two modes, but they solve different problems and shouldn’t be designed as if they were one feature.

Before you build

Four things to decide before you scan anything.

None of these are hard decisions, but skipping them is the usual reason a scanning app gets rebuilt three weeks in.

One symbology or several — a warehouse full of Code 128 asset tags is a different build than a shelf of mixed UPC and QR codes
One extra field or five — quantity and location are cheap to ask for at scan time; five required fields will slow every scan down
Live sync to one shared sheet, or a per-shift export — real-time sync needs a connection; export works offline all day
Who can edit a row after it's scanned — a fat-fingered quantity is common, so decide who gets to fix it and how

Where this fits

When an off-the-shelf scanner app runs out of settings.

Generic barcode scanning apps exist, and they’re the right call if the workflow really is “scan a UPC, look up the product.” The moment it branches — a second confirmation step, a custom field like batch number or condition, routing scans to different sheets by location or shift, or combining a barcode scan with a photo — a fixed consumer app runs out of settings well before your process runs out of edge cases.

That’s the point where teams end up building their own tool instead: something that scans, asks the one or two extra questions the workflow actually needs, and writes the row the team’s spreadsheet already expects. Newly is built for that gap specifically — camera access and a database are both native building blocks, so describing this workflow produces a real app your team can keep changing as the process changes, not a generic scanner with a logo swapped in.

A generic scanner app handles

One symbology, decoded and shown on screen
A single fixed field per scan (usually just the code)
A local list you can copy or email out
Simple product or asset lookups

Your process usually also needs

Extra fields per scan — quantity, location, condition, who
Multiple people writing into one shared, running log
Rows routed to different sheets by shift, site, or team
A spreadsheet export that matches the one you already use

A generic app rarely does the right-hand column without a custom build — that gap is usually the whole reason the search for a scan barcode to Excel app started.

FAQ

Scan barcode to Excel app, answered.

Not in one motion, but close. The phone camera decodes the barcode on-device, an app records that value as a row (usually with a timestamp and whoever is signed in), and that log is what becomes your spreadsheet. Most scan barcode to Excel apps export the log as a CSV or XLSX file you open in Excel, or sync it live to a shared sheet. No dedicated scanner hardware is required for most retail, office, or light-warehouse volumes.

Ready to build your scan to Excel app?

Describe the workflow — what gets scanned, what else you need to record, and where the spreadsheet should end up — and start building a real app around it.

Start building

Scan barcode to Excel app:the real build guide.