Updated October 1, 2026
Search for a card scanner and every result is an app install. App Store, Play Store, 200 MB, an account, notification permissions, and an icon on your home screen for a thing you'll use for one weekend while you catalogue a shoebox.
There's another way to do it: open a URL, point your camera, done. This guide covers how browser-based card scanning actually works, where it genuinely loses to a native app, and where it doesn't.
A modern mobile browser can do nearly everything a card scanner needs:
getUserMedia gives a web page a live camera feed, at full resolution,
with the same permission prompt a native app gets.card.onnx) that
runs client-side through onnxruntime-web: finding the cards in your photo happens on
your phone, not on a server. That's not a simplification for this article — it's the same
pipeline our published benchmark measures, driven through a real headless browser.What still needs a server is identification: matching a cropped card against a catalogue of millions, and retrieving pricing from completed sales. No phone holds that catalogue, and a native app doesn't either — it makes the same network call you do.
Being straight about this, because "no download" articles usually aren't:
| Native app | Browser |
|---|---|
| Home-screen icon by default | You bookmark it, or Add to Home Screen |
| Push notifications | Limited and awkward on iOS |
| Full offline use | Needs a connection to identify |
| Background processing | No |
| App Store discovery | None — you have to be told the URL |
And what you don't give up: camera quality, detection accuracy, image resolution, or speed of capture. The camera API hands the page the same frames.
Worth being explicit about one more: SnapMyCards is a web app, not an installable PWA today — there's no web manifest, so "Add to Home Screen" gives you a bookmark rather than a true standalone app window. That's a real gap and we're not going to describe it as a feature.
The browser part is not what determines your results — layout is. From our detection benchmark
(50 photos, 373 cards, detector build 25222858):
| Layout | Cards found |
|---|---|
| Flat, non-overlapping | 311 / 313 (99%) |
| Fanned, piled, overlapping | 33 / 60 (55%) |
Almost every miss in the benchmark came from cards covering each other. So:
Full detail in bulk card scanning.
Identification is a separate thing from detection, and it's weaker. On our end-to-end benchmark of 192 cards, the pipeline was confident on 120 — and 15 of those 120 were the wrong card. That's why bulk imports go to a review queue instead of straight into your collection, and why you should be sceptical of any scanner, browser-based or native, that doesn't tell you its error rate. More on that in what a collection tracker has to get right.
Yes. A browser can access your camera at full resolution and run the card-detection model on-device through WebAssembly, so scanning works from a URL with nothing installed. Only identification — matching the card against a catalogue and retrieving pricing — requires a server, and native apps make that same network call.
The camera API gives a web page the same frames a native app gets, and in our case the detection model runs client-side in the browser either way, so image quality and detection are unaffected. What a browser gives up is offline use, push notifications, background processing and app-store discovery.
Detection runs on your device. The detector is an ONNX model executed in the browser via onnxruntime-web, so finding the cards in a photo happens locally. Identification and pricing require a server call because no phone holds a catalogue of millions of cards.
You can bookmark it or use Add to Home Screen. Being precise: SnapMyCards has no web manifest today, so that gives you a shortcut rather than a true standalone app window.
Yes. The same account and the same collection work from any device with a browser and a camera, with no per-device install.
Try SnapMyCards — it runs in your browser