Processed locally
Your input stays in this browser.
A batch is a list of independent images
Select PNG, JPEG or WebP files and the reader creates an in-memory canvas for each file. The files are never posted to a server. Each row records filename, decode result and status, so one damaged photograph does not hide the readable results behind it. The order follows the selected files, not a guessed chronological order from image metadata.
What the decoder returns
A QR reader normally returns a payload string or bytes. It cannot certify the meaning of that string. For example, `https://example.org/a` is a decoded destination, while a Wi-Fi record or vCard still needs an appropriate receiving application. The batch result deliberately shows text rather than auto-opening links, because decoding and navigating are separate actions and an uploaded code can be untrusted.
Worked receiving example
Imagine four proof files: `menu.png`, `wifi.jpg`, `badge.webp` and `blurred.jpg`. The first may return a URL, the second `WIFI:T:WPA;S:Guest;P:tea2026;;`, the third a serial number, and the fourth no result. Exporting the table preserves that distinction. A single overall pass mark would be misleading because the files represent different payload contracts and one failure needs its own image diagnosis.
Why duplicate text is not necessarily an error
Two labels may intentionally share a destination: table tents, cartons from the same lot, or repeated signs. The reader flags duplicate payloads for review but does not reject them. Conversely, visually identical filenames can contain different payloads. Compare the decoded value with the approved source list before deciding that a duplicate or difference is operationally wrong.
Common reasons one row fails
The QR may occupy too few pixels, be out of focus, be heavily skewed, have glare across a finder square, or have a cropped margin. It may also be a barcode rather than a QR code. A Not decoded status is an observation, not empty data: retain the original export and make a controlled comparison before changing an approved payload.
Memory and privacy boundaries
Browsers must read a local file into memory to decode it. Large batches of high-resolution photographs can consume memory and become slow, even though no network request occurs. Close the page or reload it to clear results. Avoid selecting files that contain unrelated personal information in their visible background; local processing prevents transmission to this site but does not make a photographed document safe to share elsewhere.
Export is a review record
The download is a CSV created in the browser with filename, status and decoded payload. It is useful for matching a print run against an approved list, but it is not a cryptographic audit trail. Preserve the original images and the expected data separately. If an identifier is sensitive, protect the exported CSV like any other list of readable labels.
A batch result is not a production verdict
A list of recovered strings does not calculate module pitch, measure a photograph's optical contrast, or establish the condition of a physical print. It is a reconciliation record for the selected files. A failed row should remain tied to its original file so that focus, cropping, glare and source-data questions can be examined without altering the evidence.
Use a controlled naming convention
A batch becomes easier to review when filenames identify the physical proof without embedding the payload itself. Names such as `menu-a4-matte.png` and `menu-a4-glossy.png` let the CSV show which print condition returned the same URL, while the approved source list remains a separate record. Do not rely on alphabetical order to imply a sequence of lots or dates. If results disagree, compare filename, image dimensions and decoded payload before changing data. The reader reports what each selected file contains; it cannot know whether `lot-17` should have contained a different value or whether the camera photographed the wrong label.
Resolve a mismatch before relabelling
Suppose `carton-17.png` returns `LOT17-A` while the approved list says `LOT17-B`. First re-read the original artwork and a second photograph of the same carton. If both return A, the printed data differs from the list; if only the photograph fails, investigate capture and print quality. Do not overwrite the CSV row with the expected text, because that removes the observation that started the investigation. Batch output is most useful when it records the evidence honestly enough for another operator to repeat the check.
Limit the claim to readable QR files
The list processor does not identify every barcode family, extract serial numbers from ordinary photographs, or repair a payload that is wrong but optically readable. It gives a deterministic local reading attempt for each selected QR image. A Not decoded row means there is no recovered QR payload from that file in this browser run, not that the associated object has no identifier.
Reconcile a labelled sample against an expected list
A print supplier returns eight proof files named `menu-matte-01.png` through `menu-matte-08.png`. The batch reader may recover the same URL from all eight, which is correct if every tent uses one menu. For a carton run, however, `carton-017.png` returning `LOT17-A` when the approved list says `LOT17-B` is a mismatch even though the QR image decodes cleanly. Export the CSV, keep it with the source list, and compare filename, status, and payload character for character. The batch reader deliberately does not open recovered URLs, because a folder can contain an unfamiliar or malicious code. Its result is an observation about selected image files, not approval of their destinations.
Separate missing data from an unreadable photograph
If `blurred-04.jpg` is reported as Not decoded, repeat the test with the original export and a second photograph of the same printed label. An original that decodes while both photographs fail points toward focus, glare, cropping, perspective, or physical reproduction. An original that does not decode is a source-artwork problem. Do not replace a failed CSV row with the expected value: that hides evidence and makes the next investigation impossible. Large batches also remain local only in the practical browser sense: image pixels must be read into tab memory, so 300 high-resolution photographs can be slow and can expose whatever is visible in their backgrounds to anyone who receives the exported report. The tool reads QR images, not every barcode family or text embedded in a photograph. A clean review record names the selected file, decoded payload or failure status, expected value, and the decision to accept, hold, or retake the proof.
Keep the CSV as a reconciliation record
Give files a physical-proof name, not a secret payload: `hall-a-placard-03.jpg` is useful; an account number embedded in a filename is not. After export, add the expected value and reviewer decision in the controlled record rather than altering the reader's raw result. If two distinct filenames return the same value, decide whether that repetition is intentional. If a payload differs by one character, retain both strings and trace the artwork source. The batch reader is most valuable when a later reviewer can reproduce its result from the same selected files, not when it makes a folder look uniformly successful.
Close each exception explicitly
A held image needs a retake, artwork correction, or documented acceptance. Leaving its blank status unresolved turns a convenient batch list into an incomplete inspection.