1D barcode decoder — JAN/EAN/UPC/Code128/Code39/ITF/Codabar

Barcode values range from product codes to personal identifiers

A barcode image looks like a simple stripe pattern, but what it encodes spans a wide sensitivity range. JAN-13 / EAN-13 on a supermarket receipt maps directly to the purchased items. Code 128 on a courier slip encodes a tracking number tied to the recipient’s name and address. Codabar or Code 39 on a hospital wristband or library card encodes a patient ID or borrower number. ITF-14 on warehouse cartons describes stock composition — internal supply-chain information. When you process a batch of images and export the results as CSV, you may be aggregating dozens of personal or business identifiers in a single operation.

Phone photos carrying barcode images also carry EXIF metadata — GPS coordinates, capture timestamp, device model. Uploading such an image to any online service means handing over both the barcode value and the capture context in a single file.

What happens when a barcode image reaches an online decoder’s server

Server-side barcode decoders receive the entire image file, EXIF and all. The decoded string — a tracking number, patient ID, or product code — typically ends up in the server’s access log as the processing result. Even if the service deletes the image promptly, the log line may persist in backups or monitoring systems.

Batch uploads amplify the exposure. Dropping twenty shipping label photos to decode tracking numbers in bulk is operationally convenient, but it sends twenty images with twenty recipients’ tracking data — essentially a partial customer delivery manifest — to an external server. Terms of service that permit using submitted content for ‘service improvement’ put those identifiers in a legally murky position.

In-browser decoding with @zxing/library and the Canvas API

This tool imports @zxing/library (Apache 2.0) as an npm package. The library reads pixel data from a Canvas element — drawn from the uploaded image using the browser’s standard Canvas API — and performs all barcode recognition in JavaScript. ZXing (Zebra Crossing) is a well-established open-source barcode library that covers JAN/EAN/UPC, Code 128, Code 39, ITF and Codabar natively, including check-digit verification.

No pixels, no barcode values, and no EXIF data leave the page. After the initial page load, opening DevTools Network and dropping an image produces zero outgoing requests — including for batch uploads. The CSV export is assembled entirely in memory and written to the clipboard via the browser’s Clipboard API.

Suited for warehouses, clinics and anywhere identifiers are sensitive

Barcode scanning scenarios that involve sensitive identifiers — medical, legal, logistics — are exactly the situations where sending images to an unknown third party is hardest to justify. This tool requires no installation, works in any modern browser, and can function from cache when offline, making it a practical option for occasional scanning without a dedicated barcode scanner or a server-connected enterprise system.

Format internals and check-digit verification per standard

Each 1D barcode format defines its own digit structure and symbology. JAN-13 / EAN-13 is specified by ISO/IEC 15420 as 13 numeric digits: a 2- or 3-digit country prefix (45 / 49 for Japan, 00–13 for the US and Canada), a 4- or 5-digit manufacturer code, an item code, and a modulo-10 check digit. @zxing/library recomputes that check digit and discards mismatched reads, which suppresses false positives even on poorly printed labels. Code 128 (ISO/IEC 15417) is variable-length with three sub-sets — Code A (uppercase + control), Code B (full ASCII), and Code C (pairs of digits in half the width) — switched by Start and Code Switch characters. Shipping labels typically use Code C to fit long tracking numbers.

Code 39 (ANSI MH10.8M) is restricted to uppercase, digits, and a few symbols, with each character encoded as 9 bars (3 wide). ITF (Interleaved 2 of 5, ISO/IEC 16390) interleaves pairs of digits and therefore only supports even digit counts. Codabar (NW-7) uses one of A, B, C, D as Start and Stop characters and persists in libraries and blood-bag identification. Knowing which standard a given label uses speeds up debugging when a scan fails.

Image-recognition pipeline and the failure modes you actually hit

ZXing converts the uploaded image to a grayscale pixel array on a Canvas, applies its Hybrid Binarizer to separate bars from spaces, extracts a run-length-style sequence of widths, then searches for each format’s Finder Pattern — the EAN-13 guard bars, the Code 128 Start character, and so on. The decoder rotates and re-scans in all four orientations, so phone photos in portrait or upside-down still work. Where it falls apart is in binarisation: heavy glare from a flash, severe perspective skew, or moiré patterns from a screen capture push the algorithm into ambiguous regions and produce no match.

In practice the recurring failure modes are: (1) JAN-13 vs JAN-8 confusion — forcing a 13-digit decoder on an 8-digit label; (2) pinning the format to Code 128 or Code 39 manually and feeding in the other type; (3) physical scuffing that has destroyed one side of the guard bars; (4) ITF input where the printed digits happen to be an odd count, which is invalid by the standard. Auto-format mode (the default) avoids (1) and (2). Problems (3) and (4) are physical defects of the original print and require either a re-issued label or a more aggressive image-cleanup step before scanning. To re-emit the decoded value as a fresh label, barcode-generate re-encodes the same 1D formats locally, and when the scanned image turns out to be a 2D code, qr-decode handles QR with the same Apache-2.0 ZXing pipeline.