Chrome ERR_TOO_MANY_REDIRECTS: check cookies for the affected site
What to do first
For a loop affecting one website, compare the URL and browsing context before clearing that site's saved data. Treat the comparison as a clue, then check normal browsing again.
This is a general troubleshooting guide, not an announcement of a current outage.
Affected products and symptoms
- Product
- Google Chrome
- Versions and conditions
- Google Chrome for desktop; a redirect error on a specific website
- Error codes and identifiers
- ERR_TOO_MANY_REDIRECTS
Symptoms
- Chrome reports too many redirects
- A page loops after sign-in or cannot finish loading
Causes and conditions
Page navigation is looping. Site cookies can contribute, but server-side redirects or authentication configuration may also be responsible.
Before you start
- Record the requested URL and exact error
- Save unfinished input and make sure you can sign in to the site again
Precautions
- Removing cookies can sign you out and reset site preferences
- Do not disable certificate checks or browser protection to bypass a redirect error
Tools and official pages used in this guide
Step-by-step instructions
Confirm ERR_TOO_MANY_REDIRECTS on the error page. If you used an old bookmark, navigate from the website's official home page to the intended page.
Certificate or name-resolution errors need a different diagnosis. Record the hostname and whether the failure occurs before or after sign-in.
Distinguish redirect looping from connectivity or certificate errors. Record whether the official public homepage works and which post-login page fails. Compare the current official entry with an old bookmark. Several authentication hosts can be normal; record the final host and time while redacting token-bearing URLs in public reports.
Open a new Incognito window from the Chrome menu and enter the same URL. On Windows, Ctrl+Shift+N opens that window.
Success suggests that the normal browsing state may matter. Failure does not prove a server fault because cookie behavior differs in Incognito.
Incognito is one comparison, not definitive proof. Normal-only failure suggests stored state or extension differences, while failure in both can still involve cookie or organizational authentication differences. Keep PC, network and official entry fixed and compare before/after login, without also changing VPN or account.
Official links for this step
Record whether failure follows the login button or the return after authentication. For SSO, identify whether the provider or application is the failing stage. Confirm relevant hosts with the administrator and do not enter passwords on unfamiliar destinations as a recovery step.
In a normal window, open Settings > Privacy and security > Third-party cookies and its site-data-and-permissions list. Search for the affected domain.
Match the listed domain with the original URL. Avoid including lookalike names or unrelated authentication services in the removal.
After preserving input and confirming your sign-in method, remove the selected site entry and confirm. Its login session and saved preferences may be lost.
Keep this trial limited to the identified site so the result can be evaluated without signing out of unrelated services.
Before removal, preserve unsaved form text, carts or draft posts and confirm access to password and two-factor methods. Match the data entry domain to the original URL and remove only that site. Ask about an unclear authentication provider rather than deleting all histories, passwords or site data.
Official links for this step
If possible, compare the same account on another authorized device. Separate browser-specific, account-specific and universal failure. Another person success does not establish this account health; include comparison conditions in the report.
Return through the official home page in a normal window, sign in if required, and repeat the original operation once.
If the loop remains, record another browser's result and provide the site operator with the URL, time and sign-in stage. Do not include cookie values or passwords.
Retest the official entry and original action once in a normal window. If it works, check continued permitted sign-in use. For recurrence, keep browser conditions fixed and record another browser result and time. Server redirect or authentication configuration can require the site administrator. Never share raw cookies or authentication codes.
Check the result
- The original page and action work in a normal window
- The loop does not return after signing in again
- The normal window completes target-site sign-in and the intended action
If the problem continues
- If a particular sign-in flow still loops, report that flow and URL to the operator
- If multiple browsers reproduce it, seek operator investigation instead of repeatedly clearing cookies
Scope of this guide
Troubleshooting guide — The normal window completes target-site sign-in and the intended action
Frequently asked questions
Does success in Incognito prove the site is healthy?
It is a useful clue, but sign-in and cookie conditions differ. Verify the original action in a normal window.
Must I delete all browsing history?
Start with the affected site's stored data. Clearing all history is not required for this targeted check.
Would deleting every cookie be faster?
It affects other sites and obscures the cause. Preserve input and confirm sign-in methods, then compare the result for one affected domain.
Official sources and dates
Source publication or resolution date: Not specified. Sources checked: 2026-10-13. The check date is not the date the problem first occurred. Interface labels can vary between versions and display languages.