What does the browser's navigator.sendBeacon(url, data) call return, and what does that return value actually tell you about whether the server received the data?

## The signature `navigator.sendBeacon(url, data)` takes a URL and an optional body and returns a `boolean`. The body may be any `BodyInit` value except a stream — a string, a `Blob`, an `ArrayBuffer` or typed-array view, `FormData`, or `URLSearchParams`. The request is always a POST; there is no argument for the method and none for headers. ```js const ok = navigator.sendBeacon('/collect', JSON.stringify({ sessionMs: 41230 })); if (!ok) { // the browser never took the payload — decide what to do about it now } ``` The call does not block. It hands the payload to the browser and returns on the same turn, which is exactly why it is usable in a handler that runs while the page is being torn down: nothing about it needs the document to survive. ## What `true` means `true` means one thing only: the user agent has successfully queued the data for transfer. Ownership of the payload has moved from the page to the browser process, and the browser will keep the request alive independently of the document — after the tab is closed or a new page has committed. That is the whole value proposition of the API. It is not a statement about the network, the server, or the response. The request may still fail DNS, be refused by the server, return a 404 or a 500, or be blocked cross-origin. None of that comes back to your code. ## What `false` means `false` means the browser refused the payload up front. The dominant cause in practice is size: beacons draw on the same in-flight keepalive quota as `fetch(..., { keepalive: true })`, and that quota is about 64 KiB of body across all in-flight keepalive requests for the document. A 300 KB error dump returns `false` every time. Other causes are a URL the page is not allowed to request — a scheme the browser rejects, or a destination blocked by the page's Content Security Policy `connect-src` directive. `false` is actionable, and it is the only signal the API gives you. Treat it as "this data is gone unless I do something": shrink or truncate the payload, drop low-value fields, split one large beacon into several small ones, or stash the payload in `localStorage` and send it on the next page load. Code that ignores the return value silently loses exactly the sessions with the most interesting data, because the biggest payloads are the ones that fail. ## Why there is no response The API is deliberately fire-and-forget. Reading a response would require a live JavaScript context to receive it, and the whole point of a beacon is that it outlives the context that created it. Handing the page a promise that could never settle would be worse than handing it nothing. So the design gives you a synchronous accept/reject on the queueing step and nothing after that. The consequence for design is that a beacon endpoint must be built to fail silently and safely on the server side: it should never rely on the client seeing a status code, never expect the client to retry on error, and should tolerate duplicates, because the client cannot tell a delivered beacon from a lost one and a retry-on-next-load strategy will inevitably double-send some payloads. ## When you need more than a boolean If you actually need the response — a server-assigned id, a validation error, an auth failure — a beacon is the wrong tool. Use `fetch()` with `keepalive: true` instead: it returns a promise resolving to a real `Response`, and if the document is still alive when the response arrives, you can read it. You give up nothing in delivery guarantees; you only take on the responsibility of handling a rejected promise, and you inherit the same ~64 KiB budget. ## Recap `true` = queued, `false` = refused. Neither says anything about the server. Check the return value, plan for `false`, and reach for `fetch` with `keepalive` when the answer matters.