← Tools I Use

Cloudflare Turnstile and the WebGL fingerprint: the privacy-friendly CAPTCHA that needs your GPU

2026-06-02 · ~7 min read · Conor Dobbs

Cloudflare Turnstile is the CAPTCHA you have probably clicked a hundred times without clicking anything. No squinting at fire hydrants, no "select all the buses." It is marketed as the privacy-friendly alternative to Google reCAPTCHA, and for most people most of the time it just works, which is exactly why it spread so fast. So it was worth paying attention when a developer documented that Turnstile was looping forever in their browser, and the reason turned out to be that it could not read a usable fingerprint of their GPU.

What people actually found

The report that kicked this off came from lanodan, who runs a WebKitGTK-based browser. On Turnstile-protected sites the widget never resolved. It just spun. Digging in, the conclusion was blunt: Turnstile wants a WebGL fingerprint of your device, and a browser that refuses to hand one over gets stuck in a verification loop it cannot pass. The test page even surfaces a telling warning when privacy protections are active: "WebGL renderer info is spoofed."

This is not one person with an exotic setup. Multiple write-ups followed within days, and the pattern they describe is consistent: users on Tor Browser, Mullvad Browser, LibreWolf with hardened settings, Cromite, and WebKitGTK-based browsers hit higher challenge rates or outright blocks on Turnstile-protected sites. The common thread is that all of those browsers either randomize, spoof, or block the fingerprinting surface that Turnstile is reading. Harden against fingerprinting and you start to look, to Turnstile, like a bot.

Cloudflare has not exactly hidden the mechanism. Their own guidance to confused users says the quiet part plainly: Turnstile uses browser fingerprinting to verify you are human, and privacy tools that block or randomize fingerprinting make your browser look like a bot. So this is not a leaked implementation detail or a bug. It is the design working as intended. The disagreement is about whether "the design working as intended" is compatible with the word "privacy-friendly" stamped on the box.

Why WebGL is such a good fingerprint

If you have never looked at how WebGL fingerprinting works, the short version is that it is alarmingly effective. The browser exposes a graphics API that, when queried, will tell you the GPU vendor and renderer strings, the driver version, the list of supported extensions, and the precise pixel output of a small hidden rendering operation. That last part matters most. The same WebGL program rendered on two different GPU-plus-driver-plus-browser combinations produces subtly different pixels, and those differences are stable.

Stable is the whole game. A WebGL fingerprint survives clearing your cookies. It survives private browsing mode. It survives switching VPNs and changing your IP. Combined with a handful of other signals, fingerprinting research has long held that you can uniquely pick out the large majority of devices, well into the high nineties as a percentage. So when a bot-detection system reads your WebGL fingerprint, it is not just checking "is this a real browser." It is computing something close to a persistent device identifier, whether or not that is how it gets described.

And that is the friction. A fingerprint good enough to tell a human from a script is, by construction, good enough to tell one human from another human across sessions. The two capabilities are the same capability. You cannot have a fingerprint strong enough to be useful that is also forgettable.

The honest take, as someone who ships on Cloudflare

I want to be fair here, because I am not a neutral party. I run a SaaS on Cloudflare Workers, this site is on Cloudflare Pages, and the free security scanner I publish runs on the same stack. I reach for Cloudflare constantly and I think the platform is excellent. So this is not a dunk. It is a developer who likes the tools noticing that one of them is doing something more invasive than its marketing admits.

Bot detection is a genuinely hard adversarial problem, and it is easy to be glib about it from the outside. The people building Turnstile are not cartoon villains. Fingerprinting is in the product because it works, and it works because the alternative, asking real users to solve image puzzles, is worse for almost everyone. There is a real reason the industry drifted toward invisible challenges: they convert better, they annoy fewer people, and they stop a lot of cheap automation. If you have ever watched a login form get hammered by credential stuffing, you understand why teams want a wall that does not require the legitimate user to do anything.

But the cost is quietly carried by exactly the people who opted into privacy. The user who installed a hardened browser specifically to resist tracking is the user who gets the endless loop. The mechanism that stops bots is the same mechanism that fingerprints humans, and the people most exposed to the fingerprinting are the ones who least consented to it. Calling that "privacy-friendly" because it does not show you a checkbox is grading the experience, not the data flow. The checkbox was never the privacy problem. The fingerprint is.

The part that should bother developers specifically is the centralization angle. Turnstile is deployed across an enormous slice of the web, which means a single vendor now sits at a chokepoint deciding which browsers are allowed to be people. Today that judgment excludes hardened privacy browsers. The list of who passes and who loops is set by one company's heuristics, and it can change without anyone voting on it. That is a lot of power to hand a CAPTCHA widget, and the fact that the widget is convenient is precisely why almost nobody is auditing it.

What I would actually do about it

If you run a site, the practical move is to stop treating any bot-detection vendor as a black box you bolt on and forget. Test your own login and signup flows in a hardened browser, not just in the Chrome profile you happen to develop in, because that is the population you are silently turning away. Watch your challenge-failure rates as a real metric, the way you would watch error rates. And keep a fallback that does not depend on a readable fingerprint, even a boring one, so that a privacy-conscious user is not simply locked out of your product with no recourse.

That instinct, do not trust the convenient automated verdict, check what it is actually doing, is the same discipline behind the small security tools and cookbooks I publish. A scanner that grades a site, a check that flags a misconfiguration, a widget that decides who is human: all of them produce a confident answer, and the confident answer is exactly the thing worth inspecting before you ship it to your users. You can find what I build at tools.thesoundmethod.me. None of it is magic. It is mostly the unglamorous habit of looking under the hood of the thing everyone else takes on faith, which, as Turnstile demonstrates, is occasionally where the interesting stuff lives.

Sources

Related reading