The captcha you solved comes straight back

The fastest fix, before any explanation: leave private browsing, allow cookies for the site including third-party cookies, reload, and solve it once more. A captcha that loops is usually a captcha whose pass could not be stored, and that is the change that lets it be stored.

What is actually happening

Solving the challenge produces a token. The token is stored — as a cookie, in local storage, or in storage belonging to the challenge vendor's own origin rather than the site's — and sent back with your next request. The site checks it and lets you through.

Every step of that can fail without anybody telling you. If the storage write is refused, there is no token. If the token is stored against a different origin than the one that reads it, there is a token but nobody can see it. If your address or your fingerprint changed between the two requests, the token may be bound to the wrong thing and rejected.

Cause one: storage refused

By far the most common. Blocking all cookies, blocking third-party cookies where the vendor needs one, or browsing in a private window that discards the pass on close — all three produce the identical symptom. Your reading's third-party storage row tests what this browser will and will not write, and prints the result of each test.

Cause two: the address is doing the scoring

On a shared or hosting-network address, the score is recomputed from scratch on each request and keeps landing below the threshold. You pass the box, the score rises briefly, and the address pulls it back down. Nothing you do inside the browser changes this.

Cause three: the geography contradiction

If your exit country and your clock disagree, the recomputed score will disagree with your just-issued pass on every request. This is the row that clears fastest: move the VPN to a server in your own country and the loop usually stops on the next attempt.

Cause four: the page changed underneath it

A blocker that cancels the vendor's own requests, or hides the element the challenge measures, can leave the flow half-finished with no error. Allow-listing the one site is usually enough.

In order

1. Leave private browsing and allow cookies for the site, including third-party cookies, for as long as it takes to get through.
2. Allow-list the site in your blocker.
3. Move the VPN to your own country, or turn it off for this site.
4. If it still loops, switch networks — a mobile hotspot — for the one thing you are trying to finish.

How long is a captcha pass supposed to last?

Longer than one page. That is the whole diagnostic value of this symptom, and it is worth stating precisely because it tells you when to stop blaming yourself for solving it wrong.

The exact lifetime is the site's choice and is not published, but the design intent is universal: you solve once and continue for a session. If you are asked again within seconds, or on the very next click, no lifetime setting explains that. Either the pass was never stored, or it was stored somewhere the next request could not read, or it was rejected on arrival because something about the request changed.

So the useful question is not “how long should this last” but “did it survive one navigation”. If it did not, work the list above rather than solving more carefully.

Why does it loop on one site and not others?

Because sites configure the same vendor very differently, and because the storage arrangement differs per site. Three ordinary explanations:

• Different protection levels. The same vendor offers a range from a light score check to an interstitial on every request. A site under attack this week is stricter than it was last week, and nothing about you changed.
• Different storage origins. Some deployments store the pass on the site's own domain, others on the vendor's. If your browser blocks third-party storage, the second arrangement loops and the first does not — same browser, same settings, different outcome.
• Different sensitivity to what you are doing. A checkout, a login and a password reset are scored harder than a product page. Looping only at payment is not a coincidence and it does not mean the site distrusts you personally.

The image puzzle that never accepts an answer

A specific variant deserves its own paragraph, because it feels like an accusation of incompetence and it is not one. You select the traffic lights, it fades and gives you another grid, and another, indefinitely.

That is not a judgment about your answers. When a challenge is unsure, it asks for more — more rounds, harder images, longer interaction — and how unsure it is was decided before the first grid appeared, from the request itself. People who report solving twenty grids are not solving them wrong; they are being asked to keep proving a point that the images were never going to settle.

The remedy is the same as the rest of this page: change something about the request, not about how carefully you click. The ranked reading tells you which thing.

What if I am on my phone?

Two differences change the odds, and they pull in opposite directions.

In your favour: a phone browser is running almost no extensions, so the page arrives at the challenge unmodified and the processor is not competing with thirty tabs. Two of the four causes on this page are much less likely there.

Against you: mobile browsers restrict cross-site storage more aggressively than desktop ones, and an in-app browser — the one that opens inside a messaging or social app rather than in your actual browser — is the strictest environment of all and frequently the reason a checkout loops on a phone. If a link opened inside another app, use the “open in browser” option and try again there before changing any settings.