Processed locally
Your input stays in this browser.
A PC generally has no built-in QR code scanner comparable to a phone's Camera app. The two practical desktop routes are a browser page that requests webcam access to scan live, or an upload-based reader that decodes an already-saved screenshot or photo, and the second route needs no camera or permission prompt at all.
Why a phone has a QR scanner built in and a PC usually does not
A phone's operating system ships with camera-based QR recognition built directly into its default Camera app, tightly integrated with the device's autofocus, exposure, and always-available rear camera, because scanning a physical code with a handheld device pointed at the world is one of the core scenarios phone cameras are designed around. A desktop or laptop PC's operating system was not built around that same scenario: Windows and macOS ship with a general camera app at most, with no equivalent built-in QR recognition layer, and many desktop machines either have no camera at all or have one positioned for video calls rather than for holding a printed object up to it. The absence of a built-in PC scanner is not a missing feature so much as a reflection of what a PC's camera, if it has one, is actually for.
Route one: a browser page with live webcam access
The first practical PC route is a web page that requests access to the machine's webcam through the browser's own permission system, then runs QR-decoding software against the resulting live video feed. This depends on the MediaDevices.getUserMedia() method, documented by MDN as the standard way a web page requests a media stream — video, audio, or both — and which always requires explicit user permission before any camera or microphone can be opened; a page cannot silently start using a webcam. This route works, but it inherits every limitation of pointing an external or built-in webcam at a printed object: most laptop webcams are not designed for close-focus work, so the printed code has to be held at a distance and angle the camera can actually focus on, which is often less convenient than on a phone.
| Route | Needs a camera? | Best for |
|---|---|---|
| Webcam-based browser page | yes, with permission | a physical code held up to the machine |
| Upload-based reader | no | a QR code already saved as an image file |
Route two: upload the image instead of pointing a camera
The second practical route sidesteps the webcam question entirely: take or receive a photo or screenshot of the QR code as an image file, then use an upload-based reader that decodes that file directly. No camera permission prompt appears, because no live camera stream is ever requested; the tool simply processes the image data you already have, whether that is a screenshot of a code shown in an email, a photo taken on a phone and transferred to the PC, or an exported PNG or SVG from a barcode generator. For a code that already exists as a file rather than a physical object in front of the machine, this route is usually both faster and more reliable than trying to get a webcam to focus on a printed page or a second screen.
Worked example: a QR code shown on a second monitor, scanned by a laptop's webcam
Someone working at a desktop who receives a QR code as an image in a chat message, and wants to confirm what it decodes to before opening it, has no physical object to point a webcam at — only a file already on the screen. Saving that image and running it through an upload-based reader takes one step and avoids the webcam entirely. Compare this with genuinely needing to scan a QR code printed on a document held up to a laptop's built-in camera: that scenario does require the webcam route, and success depends on the webcam's focus distance, the room's lighting, and holding the document steady, none of which apply when the code was already available as a file and could simply have been uploaded instead.
Why the upload route is often the more reliable choice on a desktop
An upload-based reader on a desktop avoids several failure points that a live webcam scan introduces: there is no autofocus to fail at close range, no hand or document movement to blur the frame, and no glare from an angled printed page reflecting a desk lamp or overhead light directly into the lens. The trade-off is that it only works when the code already exists as a digital image file — it cannot help with a QR code printed on a physical object that has not been photographed yet. For the common desktop case of verifying a code that arrived digitally, rather than one encountered printed on something in front of the machine, the upload route removes an entire category of camera-specific problems before they can happen.
Common PC scanning mistakes
A common PC mistake is trying to scan a QR code by pointing a laptop's webcam at a second monitor or phone screen displaying the code, which introduces screen refresh artefacts and moiré patterns on top of whatever focus and glare problems already apply to any screen-to-screen capture; saving the code as an image file first and using an upload-based reader avoids this entirely. Another is denying or ignoring the browser's webcam permission prompt and then assuming the scanning page itself is broken, when the actual cause is that getUserMedia() correctly refused to start the camera without permission, exactly as the method is specified to behave. A third is using a webcam scanning page in a browser tab that has been backgrounded or minimized, where some browsers throttle or pause video processing for inactive tabs, producing a scanner that appears frozen rather than failed.
What neither desktop route can do
Neither the webcam route nor the upload route on a PC can verify that the code's destination is trustworthy once decoded, and neither can compensate for a QR code that is genuinely damaged, low-contrast, or missing its quiet zone in the original artwork — a desktop tool decodes what the image or camera feed actually shows, nothing more. Both routes also depend entirely on the browser correctly implementing the underlying web standards; an unusually old or restricted browser can block camera access outright regardless of correct permissions, or fail to render certain image formats an upload-based reader expects. For most everyday desktop needs, the upload route remains the simpler and more predictable of the two, precisely because it depends on fewer moving parts.
A third route for technical users: decoding from a script
Someone comfortable with a command line has a third option neither a phone nor a casual browser session offers directly: decoding QR images programmatically using an installed library, as part of a script that processes many files without opening a browser tab at all. This route trades the convenience of a graphical tool for repeatability — the same script run against a folder of a hundred saved images produces a hundred consistent results without any manual clicking — but it puts the burden of correctly installing and configuring the decoding library entirely on the person setting it up, with none of the guardrails a purpose-built web page provides. For most one-off desktop needs, an upload-based web reader remains faster to reach for; the scripted route earns its place specifically when the same decoding task will be repeated many times as part of an automated process. It is also the route that scales cleanly when the input is not a folder of individual image files at all but something like a multi-page scanned document or a bulk export from another system, where a script can extract each embedded image and decode it in one pass, a task that would be tedious to perform one file at a time through a web page's upload control. The trade-off to weigh honestly before choosing this route is maintenance: a script written once and never revisited can quietly stop working after a library update changes its expected inputs, while a web-based tool used directly in a browser is maintained by whoever runs that page, not by the person relying on it. MDN Web Docs: MediaDevices.getUserMedia() is the named source for the current external rule or product behaviour.