Scan QR Code

Drop in a photo or screenshot of a QR code — or point your camera at one — and read exactly what is inside it. The decoding happens in this browser tab, so the image is never uploaded, and whatever the code contains stays between you and your own device.

Why uploading a QR code image is worse than it sounds

Most free QR readers work by sending your picture to a server. That sounds harmless until you think about what people actually put in QR codes. A café code holds the Wi-Fi password in plain text. A payment code holds a link tied to an account. A conference badge holds a name, employer, phone number and email. An internal code on an office wall holds a hostname nobody outside the company was meant to learn. A login code holds a token that is, for a few minutes, as good as a password.

When you upload the image, all of that arrives at somebody else in one piece — already decoded on their side, already timestamped, already attached to your IP address. Nothing about the transaction is visible to you, and the privacy policy that governs it is usually a page you never read on a site you found through a search result.

This page has no server to send anything to. The file is read by the browser you are already using, the pixels are examined locally, and the result appears without a single byte crossing the network. You can confirm that yourself: open DevTools, switch to the Network tab, and scan an image. Nothing new appears.

The address is shown, never opened — and that is the point

A QR code is an address your eyes cannot read. That single fact is what makes an entire category of fraud work. Someone prints a sticker with their own code and puts it over the real one on a parking meter, a restaurant table, an electric vehicle charger or a payment terminal. You scan it because you trust the object it is stuck to, and your phone takes you somewhere else entirely. The technique has a name — quishing — and it works because the usual scanner opens the link before you have any chance to look at it.

So this page does the opposite. It prints the decoded address in full, as plain selectable text, and stops there. It is not turned into a link. Nothing is prefetched. Nothing redirects. You read where it goes, and then you decide.

It also points out the structural details that are easy to miss when you are reading a long address on a small screen: a missing https, a domain written in punycode so that letters can be swapped for lookalikes, a bare IP address instead of a hostname, an unusual port, or an "@" in the middle — the classic trick where everything before the "@" is only a username and the real destination is the part after it. These are observations, not a verdict. We do not keep a blocklist, and we will not check the address against an outside service, because doing that would mean sending the very thing you came here to keep private.

Why a scuffed, torn or partly covered code still reads

QR codes carry Reed–Solomon error correction, and the person who generated the code chose how much of it to include. There are four levels: L recovers from roughly 7% damage, M around 15%, Q around 25% and H around 30%. The correction data is spread across the whole symbol rather than kept in one corner, which is why a code can survive a coffee ring, a fold, a scratch or a logo dropped into the middle of it and still decode perfectly.

That budget is also why the same text produces a physically larger code at level H than at level L — the extra robustness is stored as extra modules. It is a genuine trade-off rather than a free upgrade, and it explains a common surprise: a code that scans fine on a clean screen but fails once printed and handled was probably generated at L.

What error correction cannot rescue is a missing corner. The three large squares are finder patterns, and a decoder uses them to work out where the symbol is and how it is rotated. Crop one off and there is nothing to recover from — the code is not damaged, it is unfindable. That is the single most common reason a scan fails here, and it is why a slightly wider crop usually fixes it.

Camera, files, screenshots — and what each one touches

The camera button asks the browser for a video stream and reads it frame by frame in the page. The frames are examined and discarded; nothing is recorded, and nothing is transmitted. Browsers only hand over a camera on a secure connection, and they ask you first — if you decline, the camera simply never starts.

Declining is not an error state here. The file path never needed a camera, so dropping an image, choosing one, or pasting a screenshot with Ctrl+V all keep working exactly as before. That matters on desktops, where there is often no camera worth using and the code arrives as a screenshot or an email attachment anyway.

Several codes in one picture are handled too. The underlying decoder reads one symbol at a time, so when the whole image yields nothing the page splits it and reads the pieces. Codes that are cleanly separated all get listed. The count shown is what was actually decoded, not a claim about how many exist in the picture — if two overlap, or one is tiny beside a much larger one, some can still be missed.