A staging site sits behind a session-cookie login. The page itself loads fine, but the request the browser makes for the URL in `<link rel="manifest">` comes back as the login redirect instead of the manifest JSON. What about that link explains it, and what is the fix?

## The symptom Everything about the page works. The document is authenticated, images load, the API works. Only the manifest is broken: the network panel shows the request to `/manifest.webmanifest` returning a 401, or a 302 to `/login` followed by an HTML response, and the browser reports that the site has no usable manifest. The instinct is to blame the path, the MIME type, or a build step that failed to emit the file. All three are normal causes of a dead manifest — but here the file is plainly being requested and plainly being answered, just with the wrong thing. ## Why the credentials do not travel Different subresource types are fetched with different defaults. A same-origin `<img>` or stylesheet request carries cookies as a matter of course. The manifest does not: it is fetched in a mode that omits credentials unless the author opts in. That default is deliberate. A manifest describes an application's public identity, and browsers avoid attaching a user's credentials to a fetch that can happen outside the normal page context. The consequence for a cookie-gated environment is direct: the server receives an anonymous request for a protected path and does what it does to every anonymous request — challenges it. The crucial and counter-intuitive part is that **this is not a cross-origin rule**. The credentials mode applies to the manifest fetch regardless of whether the manifest lives on the page's own origin. Engineers who reason "it's same-origin, so cookies obviously go" get stuck here for a long time. ## The opt-in ```html <link rel="manifest" href="/manifest.webmanifest" crossorigin="use-credentials"> ``` The `crossorigin` attribute on the manifest link is what changes the fetch mode. With `use-credentials`, the request carries cookies and HTTP authentication, the auth gate lets it through, and the JSON arrives. The attribute has two other states, and knowing them keeps the answer precise: - **absent** — the default no-credentials fetch, which is exactly the behaviour causing the bug. - **`crossorigin` or `crossorigin="anonymous"`** — the same no-credentials behaviour stated explicitly. Writing this does *not* fix the problem, which is a common wrong turn: people add the attribute, keep the default value, and conclude the fix does not work. ## Cross-origin manifests If the manifest genuinely lives on another origin — a shared CDN, say — then `use-credentials` is not the whole story. The response must also carry CORS headers that permit a credentialed read: an `Access-Control-Allow-Origin` naming the page's exact origin (a wildcard is not accepted for credentialed requests) together with `Access-Control-Allow-Credentials: true`. Getting one and not the other produces a fetch the browser makes and then refuses to hand over. For a same-origin manifest none of that applies; the attribute alone is enough. ## The other fix, and which to choose The second option is to leave the markup alone and exempt the manifest path from the authentication gate — allow `/manifest.webmanifest` (and typically the icon assets it references) through unauthenticated. Which is right depends on why the gate exists: - **A staging password wall** whose purpose is keeping an unfinished product out of search results and casual view: exempting a JSON file that lists a name, colours and icon URLs leaks nothing meaningful. This is usually the cleaner fix, because it also makes the icons load and keeps production and staging markup identical. - **A genuinely private application** where even the app's existence and branding are sensitive: use `crossorigin="use-credentials"` and keep the file behind the gate. A detail worth stating out loud: the icons referenced *from* the manifest are separate fetches with their own rules. Fixing the manifest fetch and leaving the icon paths behind the gate gets you a manifest the browser accepts and an icon set it cannot load. ## How to diagnose it in general When a manifest is fetched but ignored, walk four checks in order: 1. **Status and body** — is the response actually the JSON, or a login page / error page wearing a 200? 2. **Credentials** — is the path protected, and is the request going out anonymously? This is the case above. 3. **MIME type** — is it served as `application/manifest+json`? A manifest served as `text/html` or `application/octet-stream` gets discarded. 4. **Content** — is the JSON parseable, and do its relative URLs resolve where you think they do? The first two are indistinguishable in a screenshot of the head; only the network response tells you which one you have.