Your contact form may be silently losing customers right now
- If your site uses reCAPTCHA v3, form submissions from a large portion of Windows users are being silently rejected. No error message. No server log. The customer just leaves.
- There is no error message on either end. The user fills in the form, hits submit, nothing happens. The server logs show nothing. The developer never finds out.
- Microsoft Edge's default tracking prevention silently breaks reCAPTCHA v3. No ad blocker required. Default browser, default settings, invisible failure.
- Edge is the default browser on every Windows 10 and Windows 11 PC - and the second most popular desktop browser globally. This is not a fringe case.
- The problem has likely been losing real enquiries for years on any WordPress or Divi site with reCAPTCHA v3 on the contact form.
A client told me their contact form was not working. They had filled everything in correctly and hit submit. Nothing happened - no error, no confirmation, just silence. I checked the server. No failed request, no log entry. From the server's perspective the submission never arrived. They were losing enquiries without knowing it, and there was no way to tell how long it had been happening.
The client had filled in the form correctly and hit submit. Nothing happened. No error message, no confirmation, just silence. I checked the server logs. Nothing there either - no rejected request, no PHP error. From the server's perspective the form submission simply never arrived.
My own testing worked fine. The form submitted normally every time. It took me longer than I would like to admit to identify what was different about the client's environment: they were using Microsoft Edge.
Not Edge with privacy extensions installed. Not Edge in Strict mode or InPrivate mode. Just Edge with its default settings, fresh out of a Windows installation, exactly as it comes on every new PC.
Why Edge Blocks reCAPTCHA by Default
Microsoft Edge ships with a feature called Tracking Prevention. It is turned on by default, set to "Balanced" - the middle of three levels. The intention is to block known third-party trackers without breaking ordinary websites. This sounds like it should not affect a contact form. The detail that matters is how Edge decides what counts as a tracker.
Edge uses the disconnect.me Tracker Protection Lists - an open source taxonomy of advertising and tracking domains maintained by a privacy non-profit and also used by Firefox. Google's reCAPTCHA infrastructure is classified on these lists as an advertising/analytics tracker. When Edge encounters a request to load reCAPTCHA's JavaScript from Google's servers on a third-party site, it evaluates the request against its rules.
Microsoft built a safeguard into Balanced mode called the "Org Engagement mitigation." The idea is that if a user has a high engagement score with Google's own properties - visits Google Search regularly, uses Gmail, watches YouTube - then Edge relaxes its tracking prevention for Google-hosted scripts on other sites. The threshold is a site engagement score above 4.1.
The problem is what happens when a visitor does not have that score. Someone who uses Bing instead of Google Search, who has not visited YouTube recently, or who simply opened Edge for the first time to look up a web designer - their engagement score with Google is near zero. Edge blocks reCAPTCHA's access to cookies and browser storage. Without that cross-site cookie access, reCAPTCHA cannot build the behavioural profile it needs to generate a meaningful score. The result comes back as 0.0. The form's server-side handler, following Google's recommended threshold of 0.5, rejects the submission and returns nothing to the user.
There is also a complete failure mode that applies to everyone. In Edge's InPrivate (private browsing) window, the engagement score for every site is always zero regardless of normal browsing history. reCAPTCHA v3 will fail for every single user who browses in private mode on Edge, without exception, without any error visible to them.
How Widespread This Is
Edge is the second most popular desktop browser in the world according to StatCounter's browser data. More importantly, it is the default browser on every Windows 10 and Windows 11 installation. Microsoft ships it pre-installed, set as the default, and actively prompts users to keep it when they try to switch. A substantial portion of Windows users - the less technically inclined ones, the ones most likely to just use what came with their computer - have never changed their browser.
The typical client for a small business web designer is not a developer who switches browsers deliberately. They are a business owner sitting at a Windows laptop who opened Edge to look up web design services. When they try the contact form and nothing happens, they do not know why. They do not file a bug report. They click the back button and try the next search result.
This is not a scenario that affected one person on an unusual setup. It is a scenario that has been affecting a percentage of every contact form submission on every Divi and WordPress site using reCAPTCHA v3 for as long as Edge's Balanced tracking prevention has been in place - and Microsoft introduced it in 2019.
How reCAPTCHA v3 Works and Why This Breaks It
Understanding why Edge's behaviour is fatal to reCAPTCHA requires understanding what reCAPTCHA v3 actually does. Unlike earlier versions, v3 never shows the user a puzzle or a checkbox. It is designed to be completely invisible. Instead, it loads a Google JavaScript library that observes browser behaviour - mouse movements, interaction patterns, timing, session context - and correlates this with data gathered from the user's history across other Google properties.
From this profile, Google's servers generate a score between 0.0 and 1.0. A score near 1.0 means Google is confident the user is human. Near 0.0 means Google either believes the user is a bot, or - critically - simply does not have enough data to assess them. Google's own documentation recommends a threshold of 0.5 for accepting form submissions.
The entire system depends on reCAPTCHA being able to read and write cookies across sessions. Block that storage access - which is exactly what Edge's Balanced mode does for users below the engagement threshold - and reCAPTCHA has no data to work with. It cannot tell whether this person is a human or a bot because it cannot see anything about them. The safe default, from Google's perspective, is a score of zero.
Most implementations treat a score below threshold as a bot. The form is rejected. The rejection produces no user-facing feedback because reCAPTCHA v3 was designed to operate silently. The server logs a rejected submission or, in many implementations, logs nothing at all because the token check happens before any request reaches the database. The developer sees an empty inbox and assumes no one submitted the form.
The Broader Problem Is Bigger Than Edge
Once I understood the Edge mechanism I started looking at what else could be causing the same failure pattern, and the list was uncomfortable.
Ad blockers. GWI data published by Backlinko puts global ad blocker usage at 29.5% of internet users as of Q2 2025, roughly 1.77 billion people. The EasyPrivacy filter list - bundled by default with uBlock Origin - explicitly blocks Google's reCAPTCHA infrastructure. Brave's built-in shields block it. Pi-hole installations using standard community blocklists block it. For these users the script never loads at all. No token is generated. The form fails.
Firefox Strict mode. Firefox's Enhanced Tracking Protection set to Strict blocks the same disconnect.me tracker categories as Edge, without the engagement score mitigation. Anyone browsing Firefox in Strict mode faces the same outcome as an Edge user with no Google engagement history.
Privacy-focused mobile operating systems. GrapheneOS and CalyxOS, hardened Android variants that operate without Google Play Services, cannot reach Google's reCAPTCHA scoring infrastructure. Every user on these platforms receives a score of 0.0 by design.
In every case the failure is invisible to the user. reCAPTCHA v3 was deliberately designed without any visible challenge - that is its primary selling point. But that invisibility cuts both ways. When it fails, it fails silently. The user has no idea. They filled in the form correctly. The button is right there. Nothing happened. They leave.
What This Means for Web Developers and Their Clients
The practical implication for anyone building or maintaining a WordPress site - and for Divi specifically, where reCAPTCHA v3 is the default spam protection on contact forms - is that there has likely been a slow leak of genuine enquiries since the site launched.
There is no retrospective audit you can run. The failed submissions were never recorded. The server never received them, or received them and discarded them without logging. The clients who bounced after a failed form submission are gone.
What you can do now is ask a harder question about your server-side handler: what happens when no reCAPTCHA token is present in a submission? If the answer is a silent rejection, you have confirmed the failure mode is live. The fix is either to add a visible fallback for users without a valid token - a traditional honeypot or server-side rate limiting - or to replace reCAPTCHA entirely with a mechanism that does not depend on Google's cross-site tracking infrastructure.
There is also a compliance angle worth considering. reCAPTCHA loads Google's JavaScript on every visitor's browser from the moment they land on the page, regardless of whether they interact with a form. Google collects behavioural data from every one of those visits. Google's own Terms of Service require you to disclose this in your privacy policy. Under GDPR and the Australian Privacy Act's data minimisation principles, embedding a third-party cross-site tracker without user consent is legally questionable. Austria's Data Protection Authority ruled in 2022 that even Google Analytics data transfers to US servers can violate GDPR - the same framework applies to reCAPTCHA.
What I Replaced It With
I replaced reCAPTCHA with Cloudflare Turnstile across every form on this site. Turnstile uses cryptographic proof-of-work challenges and browser environment checks to distinguish humans from bots. It does not rely on cross-site cookies. It does not load scripts from Google. It is not present on disconnect.me's tracker lists, which means Edge's tracking prevention does not touch it, and neither do the common ad blocker filter lists.
The user experience is identical to reCAPTCHA v3 - no puzzle, no checkbox. But the verification mechanism works for users on Edge with zero Google engagement, for users with uBlock Origin, for users in InPrivate mode, and for users on GrapheneOS. The forms work because Turnstile does not need to surveil anyone to function.
Cloudflare offers Turnstile free up to one million challenges per month - a figure that represents the entire annual load of a small business website many times over.
The migration was straightforward. The contact form now delivers every submission I can test for. The harder part is accepting that the previous setup was silently losing enquiries for years, from visitors who had done nothing unusual except use the default browser that came with their Windows computer.
If your business website uses reCAPTCHA v3 on its contact form - particularly if it is built on Divi or a similar WordPress page builder - there is a reasonable chance submissions are silently failing for Edge users right now. Get in touch if you would like me to check your setup.
