Read a linear or 2D barcode from an image or camera. Verifies the GS1 check digit, corrects a UPC-A that a browser reports as a thirteen-digit EAN-13, and names which decoder answered.
Related reading
Initializing in your browser…
Scan QR codes from an image or your camera, in this tab. Reads every code in a picture, rescues a faded or transparent one and says which step worked, and parses WiFi, vCard, calendar, geo and payment payloads by their published grammars.
See an image through the two published models of colour vision deficiency, Machado 2009 and Vienot 1999, computed in linear light where those models are defined, with the colour pairs that stop being distinguishable listed by name.
Whole-pixel crops with the rectangle typed or dragged, checked by decoding the output and comparing it with the pixels that went in. Quarter turns and mirrors are exact permutations, so nothing is clipped.
A photograph of a UPC-A on a product label, read in Chrome.
Printed under the bars
036000291452
What the page shows
UPC-A 036000291452 The decoder returned 0036000291452, because an EAN-13 whose first digit is 0 has the parity pattern LLLLLL, which is exactly UPC-A's left group. GS1 modulo 10 check digit is 2, which is what the other digits give. Read by BarcodeDetector, reported as ean_13
Chromium has no UPC-A support at all: it is absent from getSupportedFormats and the constructor accepts it anyway, so a UPC-A is read as an EAN-13 and comes back with a leading zero. Thirteen digits will not match a product database. The page shows the printed twelve-digit form, keeps what the decoder said beside it, and verifies the check digit.
Read a linear or 2D barcode from an image or your camera. The value is checked rather than just displayed: the GS1 check digit is verified, a UPC-A read as a thirteen-digit EAN-13 is corrected to the number printed under its bars, and the page names which of the three decoders answered.
Read a product barcode from a photo and get the number that a database will actually match, with its check digit verified.
Decode warehouse or shipping labels, including Codabar and ITF, and export a session as CSV.
Tell an ISBN from an ISMN or an ISSN by its GS1 prefix rather than guessing from the first three digits.
The reader asks three decoders in order and tells you which one answered. First the browser's own Barcode Detection API, and only for the formats it actually reports through getSupportedFormats: the page lists them, because the list is not what you would guess. Chromium supports Aztec, Code 128, Code 39, Code 93, Data Matrix, EAN-13, EAN-8, ITF, PDF417, QR Code and UPC-E, and it supports neither UPC-A nor Codabar. Its constructor accepts both without complaint, so asking for them looks like it works and simply never returns them; those two fall through to html5-qrcode and then to @ericblade/quagga2, which is tried at three locator patch sizes.
That gap causes the correction the page makes most often. A UPC-A has no native support, so the browser reads the symbol as an EAN-13 and hands back thirteen digits. Measured against a corpus rendered here from the ISO/IEC 15420 digit patterns, with the payload chosen in advance, the UPC-A 036000291452 came back as 0036000291452, which is not the number printed under the bars and does not match a product database. The page shows the twelve-digit form, shows what the decoder returned, and says why: an EAN-13 whose first digit is 0 has the parity pattern LLLLLL, which is exactly UPC-A's left group, so the two draw identical bars and no decoder can separate them from pixels.
Every numeric symbology gets its GS1 modulo 10 check digit verified, with the expected digit named when it does not match, so a misread is visible rather than silently copied into a spreadsheet. The leading digits are read against the GS1 prefix allocation: 978 and 979 excluding 979-0 are an ISBN, 979-0 is an ISMN and is printed music rather than a book, 977 is an ISSN, 98 and 99 are coupons, and a 2 prefix is numbered inside one shop and means nothing outside it. Codabar's start and stop characters are kept and explained. An ITF symbol with an odd number of digits is flagged, because interleaved 2 of 5 encodes digits in pairs.
A linear symbol carries no error correction of any kind, so a faded print is worth rescuing rather than rejecting: a picture that does not decode straight away is contrast-stretched, converted to grey under Rec. 709 and sharpened, each step tried in turn and each one timed, and the page lists what was tried and which one worked. When nothing does, it prints the measured contrast ratio between the darkest and lightest parts of the picture, the size in pixels against the 95 modules an EAN-13 needs, and states plainly that a scratch or a fold across the bars removes data rather than obscuring it, which is the difference between this and a QR code. Camera mode draws each frame to a canvas and runs the same native detection on it, stopping the stream on the first read. Scans accumulate in a session list with an RFC 4180 CSV export carrying the symbology, both spellings of the value, the check-digit verdict and the decoder that answered.
EAN-13, EAN-8, UPC-A, UPC-E, Code 128, Code 39, Code 93, Codabar and ITF, plus the 2D symbols QR Code, Data Matrix, PDF417 and Aztec. The page lists which of those your own browser handles natively and which fall through to the JavaScript decoders.
Because that is what the decoder returned. Chromium has no UPC-A support at all, so it reads the symbol as an EAN-13 with a leading zero, which is legitimate: the two draw identical bars. The tool shows the twelve-digit form printed under the bars as the answer and keeps the thirteen-digit form beside it.
Sometimes. A faded or low-contrast print is contrast-stretched, greyed and sharpened before being given up on, and the page says which step worked. Physical damage is different: a linear barcode has no error correction, so a scratch or a fold across the bars removes data rather than obscuring it.
The check digit says whether it is internally consistent, and the page shows that verdict. For EAN, UPC and ITF-14 the last digit is derived from the others by the GS1 modulo 10 rule, so a single misread digit almost always fails it.
QR Code, Data Matrix, PDF417 and Aztec are all requested from the browser detector and read when it supports them. For a QR code specifically, the dedicated QR reader also parses the payload into its fields.
Images are decoded, edited, and exported entirely inside this browser tab. No originals, exports, or metadata are uploaded.