Your telemetry endpoint expects JSON, but requests sent with navigator.sendBeacon('/collect', JSON.stringify(payload)) arrive with Content-Type: text/plain;charset=UTF-8. Why does that happen, and what are your options?

## Where the header comes from `navigator.sendBeacon(url, data)` takes exactly two arguments. There is no third options object and no way to attach headers. The browser therefore derives the `Content-Type` from the *type of the body value* you handed it, the same way the Fetch specification extracts a content type from any `BodyInit`: | Body you pass | Content-Type the server sees | | --- | --- | | `string` | `text/plain;charset=UTF-8` | | `URLSearchParams` | `application/x-www-form-urlencoded;charset=UTF-8` | | `FormData` | `multipart/form-data; boundary=…` | | `Blob` | whatever the blob's `type` is, or none if empty | | `ArrayBuffer` / typed array | none | `JSON.stringify(payload)` produces a string, so the beacon is labelled `text/plain`. The bytes on the wire are perfectly good JSON; only the label is wrong. A server that dispatches on `Content-Type` — a framework body parser configured for `application/json`, for instance — will hand your handler an empty body and the data looks lost. ## Option 1: accept text/plain on the server The least fragile fix. Configure the collector to read the raw body and `JSON.parse` it regardless of the declared type. This is what dedicated analytics endpoints usually do, and it has a real advantage beyond convenience: `text/plain` is one of the three CORS-safelisted content types, alongside `application/x-www-form-urlencoded` and `multipart/form-data`. A cross-origin POST carrying one of those needs no preflight, so the beacon is a single request that can be fired and forgotten. ## Option 2: send a typed Blob ```js const blob = new Blob([JSON.stringify(payload)], { type: 'application/json' }); navigator.sendBeacon('/collect', blob); ``` This genuinely sets the header. Same-origin, it is a clean solution. Cross-origin it is a trap: `application/json` is *not* CORS-safelisted, so the request is no longer a simple one and the browser must send an `OPTIONS` preflight first and wait for the response before the real POST goes out. Two round trips fired as the document is being destroyed is exactly the situation you were trying to escape, and the endpoint must also be configured to answer the preflight with the right `Access-Control-Allow-Headers` and `Access-Control-Allow-Methods`. Many teams discover this as "our beacons work in staging and vanish in production", staging being same-origin. ## Option 3: use fetch with keepalive ```js fetch('/collect', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(payload), keepalive: true, }); ``` Same delivery guarantee as a beacon, plus arbitrary headers, an explicit `credentials` choice, and a `Response` you can inspect if the page is still alive. The same preflight caveat applies cross-origin — that is a CORS rule about the content type, not a beacon quirk — but at least you can see the failure, because the promise rejects instead of returning a bare `false`. ## Option 4: sidestep the content type entirely If the server is easier to change than the client is, `URLSearchParams` gives you a safelisted `application/x-www-form-urlencoded` body with real key/value structure and no preflight: ```js navigator.sendBeacon('/collect', new URLSearchParams({ event: 'exit', ms: String(t) })); ``` It is not JSON, but for flat counter payloads it is often a better fit, and it is the choice with the fewest moving parts cross-origin. ## The rule to remember With a beacon, the body type *is* the header. Pick the body type for the `Content-Type` you want the server to see, and remember that only `text/plain`, `application/x-www-form-urlencoded` and `multipart/form-data` avoid a preflight cross-origin. When you need a content type outside that set, use `fetch` with `keepalive` so you at least keep visibility into what went wrong.