Can You Skip Google's QR Code at Signup?

If Google's signup page just told you to scan a QR code with your phone, nothing is wrong with your browser or your account. Google announced in February 2025 that it would stop texting codes to new accounts in some cases, and a spokesperson told CyberScoop: "In certain situations we're replacing SMS when creating a new account." The rollout is regional and gradual, which is why one person sees the QR code and the next person gets a normal text message.

Why Google Asks You to Scan a QR Code

The short answer: Google wants proof that a real phone number belongs to you, and it no longer trusts a texted code to prove it.

A six-digit code sent by SMS can be phished, intercepted, or requested in bulk. Google's Gmail spokesperson said the company wants to "reduce the impact of rampant, global SMS abuse", and TechRadar's report on the change lists the problems QR verification avoids: codes phished out of users, dependence on each carrier's fraud controls, and "traffic pumping", where fraudsters trigger mass SMS sends to premium numbers and collect a share of the fees. 9to5Google adds the other motive: making it harder to create Gmail accounts used for spam and malware.

Google's own 2-Step Verification help page describes the step in plain terms: "In certain cases, Google will require that you scan a QR code with your mobile device to verify. This method is less vulnerable to phone number-based attacks and abuse." Its account verification page says phone verification can be required "before you create an account or sign in" and that Google limits "the number of accounts each phone number can create."

What the scan actually does

The QR code flips the direction of the check. Instead of Google texting a code to you, scanning the code opens a prepared message on your phone, and your phone sends the SMS to Google. CyberScoop confirmed that "in some cases the phone will still send an SMS to Google to complete verification." Proving that a number can send from a real handset is much harder to fake than proving it can receive a code.

What to do when you see it

• Scan it with any phone that can send a text. Point the camera at the screen, send the message it prepares, then go back to the computer to finish. Google's help page asks only that you use your mobile phone; it does not say the phone has to be signed in to a Google account.
• If your number is refused, one common reason is Google's per-number account limit. Google's verification page suggests using another number you can access, such as a family member's.
• Setting up an account for a child? The create-account form has a separate Child option for parents setting up a supervised account.

For most people, that is the whole story. The rest of this post is for a different audience: people who run account creation from desktop browsers, antidetect profiles or proxies, where the QR wall appears every time and scanning a phone is not part of the workflow.

What Decided QR or SMS in Our Testing

This change broke a lot of existing account-creation setups, and it did it in a way that IP quality alone could not fix. We tested residential mobile proxies, premium VPNs, UK and Japanese exit nodes. None of them got past the QR code wall from a desktop connection. Multilogin's 2026 documentation confirms the same wall affecting their entire user base. If you're coming from the broader guide on creating accounts without a phone number, this is the 2026-specific wall that changed things.

Google has not published how it picks who gets the QR code; its statements only say "in certain situations". What follows is what our own tests showed, and the pattern was consistent: this isn't about IP reputation. The outcome followed the TCP/IP fingerprint of the connection, and that says a lot about where device-class detection is heading.

Why Every Proxy and VPN Failed: The p0f Problem

Here's what's actually happening at the network level.

Our results point to passive OS fingerprinting, commonly known as p0f: classifying the incoming connection before the signup page even fully renders. p0f analyzes TCP SYN packet characteristics: initial TTL values, window size, MSS, TCP options ordering, and the DF bit. Each operating system leaves a distinct signature in these values. Windows 10 looks different from Windows 11, Linux looks different from macOS, and critically, iOS looks different from all of them.

In our tests, when the connection carried a desktop OS fingerprint (Windows, Linux, standard macOS), the signup flow went to QR code verification. When it carried a mobile OS fingerprint, specifically iOS or Android, Google offered SMS verification instead. At this layer, that was the whole decision we could observe.

The cleanest residential IP on earth didn't change this. If the TCP fingerprint said "Windows," we got a QR code. Modern bot detection systems operate at multiple layers simultaneously. FingerprintJS's 2025 analysis documents this multi-layered approach combining server-side TLS fingerprints, client-side JS attributes, and cross-verification. But p0f operates before any of that JavaScript even runs.

The Partial Success That Revealed Everything

Attempt #5 failed, but it revealed the actual bypass mechanism.

We tried a generic mobile proxy provider that offered what they called "iOS fingerprinting." It partially worked. Google's signup page actually showed the SMS verification option instead of the QR code. The first time in our entire testing sequence.

But then a completely different wall appeared. Google sent the verification through an iMessage-style deep link that tried to open Apple's Messages app directly. On a desktop browser, even one spoofing mobile Safari, there's no Messages app to open. The whole flow dead-ended at an "Open in Messages" prompt with no fallback to a standard SMS OTP input field.

So the iOS p0f fingerprint was clearly the key to bypassing the QR code at the network layer. But the browser fingerprint needed to match a device that could plausibly receive SMS through a standard input field, not an app deep link.

That pointed directly to the macOS Safari combination.

Why the iPhone-Network + macOS-Browser Combination Passed

The combination works because of how Google splits verification logic across layers.

macOS Safari is a desktop browser that shares Apple's ecosystem identity. Google's system sees an iPhone TCP fingerprint at the network layer (mobile device, so SMS verification eligible) combined with a macOS Safari browser fingerprint at the application layer (desktop Safari, so standard SMS input field instead of Messages deep link).

Google's verification logic reads this as someone on an iPhone hotspot browsing from their Mac, one of the most common multi-device scenarios in Apple's ecosystem. No flags raised. This is consistent with how browser fingerprinting works in practice: platforms cross-reference network-layer signals against application-layer signals, and any inconsistency is a detection trigger.

What the working stack consisted of

The setup that got routed to SMS in our testing had three parts: a premium dedicated mobile proxy (not shared or rotating) set to a mobile-class TCP fingerprint profile, an antidetect browser presenting a macOS Safari profile, and a carrier-based non-VoIP number for the SMS step.

Why every layer had to agree

The reason this combination held up comes down to consistency across layers rather than any single magic setting. Google reads the TCP fingerprint (network layer), the browser fingerprint (application layer), DNS, and WebRTC together, and scores any contradiction. The stack that passed told the same story at every layer: a mobile-class TCP fingerprint, a macOS Safari browser, carrier-native DNS, and no WebRTC leak.

The failures were the instructive part. A desktop TCP stack put us straight back at the QR wall. A leaking WebRTC exposed the real machine's OS and broke the picture. A mobile-Safari browser fingerprint triggered Google's Messages-app deep link instead of a standard SMS field. Carrier-native DNS mattered for the same reason: a real iPhone on a carrier uses that carrier's resolvers by default, so a third-party resolver is one more detail that does not match. See the carrier-native DNS deep dive for why DNS is part of the fingerprint.

What happened after signup

Once the fingerprint was consistent, the signup itself was unremarkable: Google offered the standard SMS field instead of the QR code, the OTP arrived on a carrier number (Google verification numbers come from the same dashboard as the proxy), and the account was created. The one finding worth noting is that trust stabilized over roughly a 72-hour window of consistent fingerprinting, after which Google's checks became much less sensitive to exact matching.

What Caused the Failures We Saw

Still getting QR code prompt: Almost always a p0f mismatch. This was the root cause in the majority of our failed attempts. Use VoidMob's fingerprint test to check canvas, WebGL, and device signals before testing the proxy's TCP fingerprint with BrowserLeaks' TCP/IP fingerprinting page or a local p0f instance. If the fingerprint reads as Linux or Windows, the proxy provider isn't actually modifying the TCP stack. They're just changing the User-Agent header, which does nothing at this layer.

SMS prompt appears but redirects to Messages app: The browser fingerprint is set to iOS Safari (mobile) instead of macOS Safari (desktop). Change the browser profile OS from iOS to macOS while keeping the proxy's p0f as iPhone. Small difference in configuration, completely different result.

OTP never arrives: Number quality issue. VoIP numbers face 60-80% rejection rates on platforms with fraud detection. Google accepts the number but never sends the code. Carrier-based numbers only. For a full breakdown of how platforms identify VoIP numbers at the signal level, see the guide on how VoIP detection works.

Account locked after 24 hours: In our experience this came down to fingerprint inconsistency between the creation session and the first re-login. Keeping the same profile and proxy endpoint through the first 72 hours avoided it; rotating IPs during that window was the most common cause of lockouts.

FAQ

Why p0f Is the Signal That Matters in 2026

Google's 2026 QR code requirement isn't going away. If anything, more platforms will adopt similar device-class detection in the coming months. Cloudflare's bot management documentation already treats network-level fingerprints as a standard signal.

We went through multiple proxy types, VPN configurations, and browser fingerprint combinations before landing on this finding. The iPhone TCP fingerprint plus macOS Safari browser fingerprint plus clean carrier IP was the only stack that reliably got routed to SMS instead of the QR code wall in our testing.

The detection layer most people don't know exists is p0f. Once you understand it, the QR code behavior stops being mysterious.