ERR_UNSAFE_REDIRECT
Chrome blocked a redirect whose target uses a scheme it won't follow, like data:, file:, or chrome-extension://.
What you see
This site can't be reached The webpage at data:text/html,... might be temporarily down or it may have moved permanently to a new web address. ERR_UNSAFE_REDIRECT
What’s actually happening
A request that should land on a normal page instead dead-ends on Chrome's error screen with ERR_UNSAFE_REDIRECT (net error 311). It fires when a server 3xx — or a JavaScript redirect resolved by the network stack — points at a scheme outside http/https/ftp. OAuth callbacks and Chrome extensions hit this most: the auth server or a rule rewrites the response toward a data: or chrome-extension:// URL and the navigation is killed. Nothing reaches the destination; the redirect is refused at the browser, not the server.
Common causes
- A server Location header points to a data: URL (Chrome has refused redirects to data: since the 2018 open-redirect/XSS hardening)
- An extension using declarativeNetRequest or webRequest redirects a web request to a chrome-extension:// resource that isn't declared accessible
- A redirect targets file:, blob:, or another non-network scheme the navigation stack won't follow from a remote origin
- An OAuth or SSO flow is misconfigured so the final hop resolves to a javascript: or data: URI instead of a real callback URL
- A URL shortener or ad redirector chains into a payload Chrome classifies as an unsafe scheme
How to fix it
- Find the offending hopRun curl -sIL <start-url> and read each Location. The one pointing at data:, file:, blob:, or chrome-extension:// is what Chrome rejects. The browser refuses it before any page renders.
- Repoint the redirect at an http(s) URLChange the server-side Location (or the JS that sets window.location) to a real https:// destination. If you need to ship inline HTML, serve it from a fetchable URL instead of redirecting to a data: URI.
- For extensions, declare the target in web_accessible_resourcesIn manifest.json add the resource under web_accessible_resources with a matching matches list. Without that entry Chrome treats the chrome-extension:// redirect target as off-limits and blocks the hop.
- Fix the OAuth redirect_uriRegister an exact https:// callback in the provider console and send that as redirect_uri. The 311 usually means the resolved callback collapsed to a data:/javascript: value the network stack won't navigate to.
Stop it recurring
Validate every redirect destination is http(s) before returning it, and treat user-supplied next= or return_to values as untrusted.