Blocked cookies make the captcha come back
When you pass a challenge, it stores a pass in your browser and checks for it on the next request. If your settings throw that pass away, the challenge has no way to know you already proved anything, so it asks again, and again.
A captcha is not a one-time door. It is a door that hands you a ticket. The ticket is a cookie, sometimes with a value in local storage beside it, and every following request shows it. That is how a site lets you through for the rest of the session instead of testing every click.
Many challenges run from the security company’s own domain, inside a frame on the site you are visiting. To the browser that is a third-party cookie. Block third-party cookies strictly enough and the ticket is never kept, or is kept where the next page cannot read it.
The settings that throw the pass away
- Block all cookies. Breaks almost every challenge flow. Blocking third-party cookies only is usually survivable.
- Private or incognito windows. The pass is kept until you close the window, then discarded. A new private window always starts from zero.
- Clear cookies on exit and cookie-cleaning extensions that run on a timer.
- Strict tracking protection in some browsers, which treats the challenge provider’s domain as a tracker.
How to fix it without giving up cookie blocking
- Find the site in your browser’s cookie exceptions (Chrome: Settings → Privacy and security → Third-party cookies → Allowed to use third-party cookies. Firefox: the shield icon in the address bar. Safari: Settings → Privacy).
- Allow cookies for the site that keeps challenging you, including third-party cookies, for as long as you need to get through.
- If you use a cookie-cleaning extension, add the site to its keep list.
Why clearing cookies does not make you new
It is natural to clear cookies when the captchas start, hoping to be treated as a fresh visitor. It does not work that way. The checks that matter read the device, the network and the browser’s own values, which survive a cleared cookie jar. Clearing cookies only throws away the passes you already earned, so you start the loop again. The reading on the home page shows how many times these sites have recognised the same device under different cookie identities.
Third-party storage
The challenge cannot store the pass it just gave you, so it asks again.
- Allow cookies for the site that keeps challenging you, including its third-party cookies, for as long as it takes to get through.
- Turn off 'block all cookies' if it is on. Blocking third-party cookies only is usually survivable; blocking all of them is not.
- Leave private browsing. A private window discards the pass every time you close it.
A row's place on your reading is one multiplication, and both halves of it are published. Neither half is a measurement.
- Surprisal −log₂ of an assumed probability of 0.4500 for “third-party storage is refused”
- 1.15 bits
- Challenge weight Blocked third-party storage — how much a bot check is judged to act on it
- 0.45
- Rank The product. It orders the rows and nothing else.
- 0.52
Why that assumption
Safari and Firefox block third-party cookies by default and Chrome's own controls are widely used, so a refusal is closer to normal than not. The weight, not the prior, is what makes this row matter.
Why that weight
Several challenge flows carry their pass across a second origin. When that write is refused, the pass cannot be read back and the challenge is re-served — which is what a captcha loop looks like from the inside.
Every assumption, with its number → · Every weight, and what is deliberately not measured →
Questions about the “Third-party storage” row
- Why does the captcha keep coming back after I solve it?
- Most often because the pass it gave you was not kept. The challenge stores a cookie and reads it on the next page; if cookies are blocked, cleared, or kept in a private window that has since closed, the next page has no pass and asks again.
- Do I need third-party cookies for captchas to work?
- For many challenge providers, yes, because the challenge runs on their domain inside the site you are visiting. You do not need them everywhere: allow them for the one site that keeps looping and keep blocking them elsewhere.
- Will clearing my cookies stop the captchas?
- No, and it often makes the loop worse. The check still reads your device and network, and you have thrown away the pass you already earned.
READ AT PRIOR TABLE ED. 1.0.0 · 2026-10-13 · ASSUMED, NOT MEASURED
The rank is taken against 15 written assumptions about how common each value is and 16 written weights about how much each one matters. 9 of them we think are probably wrong. Real counts from the browsers these sites have read appear beside a row, never inside its rank. Read the assumptions →
The rows you cannot fix from a settings page
A VPN you need for work, an address your ISP shares with a thousand other subscribers, a laptop with no graphics chip, a hardened profile that breaks the sites it was meant to protect — none of these have a checkbox. What is left is to present a reading that is internally consistent and ordinary on purpose, instead of one that is accidentally strange.
Donut Browser does that at the engine level: its Wayfern Chromium fork applies the fingerprint through CDP injection rather than patching JavaScript in the page, and it refuses to launch a profile whose proxy exit country, time zone and language contradict the profile's own fingerprint — which is the top row of most readings on this site. It is AGPL-3.0, it has no telemetry of any kind, and it runs on macOS, Windows and Linux.
Stated plainly: this site has no test results showing what any particular anti-bot service does with any particular browser, and neither does Donut Browser's own repository. What can be checked is the source, which is public.
Free · AGPL-3.0 · github.com/zhom/donutbrowser