What does the keepalive: true option on the browser's fetch() give you that navigator.sendBeacon does not, and what limit does the browser place on keepalive request bodies?

## The same guarantee, different ergonomics `keepalive` is a boolean in the `fetch()` init object. Setting it tells the browser to keep the request alive independently of the document that started it, which is precisely what `navigator.sendBeacon()` does under the hood. Delivery-wise the two are equivalent. Everything else about them differs. ```js fetch('/collect', { method: 'POST', headers: { 'Content-Type': 'application/json', 'X-Client-Build': buildId }, body: JSON.stringify(payload), credentials: 'include', keepalive: true, }); ``` What that buys you over a beacon: - **Any method.** A beacon is always POST. With `fetch` you can `PUT` to a per-session key, which makes retries idempotent on the server. - **Real headers.** A beacon derives its `Content-Type` from the body type and offers no way to set anything else. With `fetch` you send `application/json`, an `Authorization` header, a schema version, a trace id. - **Explicit credentials and mode.** You choose `omit`, `same-origin` or `include`, and you choose `cors` or `no-cors`, instead of taking the beacon's fixed behaviour. - **A readable response.** `fetch` returns a promise resolving to a `Response`. If the document is still alive — the common case for a send at `visibilitychange` to hidden, since the user may come back — you can check `response.ok`, read a server-assigned id, or log a rejection. What you give up is that `fetch` is not fire-and-forget: it produces a promise, and an unhandled rejection during teardown is noise at best. Attach a `.catch()` even if the handler does nothing. ## The 64 KiB budget Keepalive requests are a resource the browser must fund after your page stops existing, so they are rationed. The cap is on the **total body size of all in-flight keepalive requests for the document**, and it is approximately 64 KiB. It is a shared pool: beacons and keepalive fetches draw on the same budget, and a request only returns its share once it completes. The failure modes differ by API, which is a favourite interview detail: - `fetch(..., { keepalive: true })` **rejects with a `TypeError`** when the body would exceed the remaining budget. - `navigator.sendBeacon()` **returns `false`**. Neither tells you it was a size problem in a machine-readable way, so treat both as "the payload was too big or the pool is full". The practical discipline is to keep exit payloads small — a handful of counters and ids, not a session replay — and to send incrementally during the session rather than accumulating one large terminal blob. If you genuinely need to ship kilobytes at exit, compress before sending, or write the payload to storage and upload it on the next visit. One more restriction: a keepalive request cannot have a `ReadableStream` body. Streaming uploads need a live document by definition, so the two features are mutually exclusive. ## Choosing between them Reach for `sendBeacon` when the payload is small, POST is fine, `text/plain` or form encoding is fine, and you truly do not care about the response. It is the simplest thing that works and it cannot leave a dangling promise. Reach for `fetch` with `keepalive` when you need JSON with the correct `Content-Type`, an auth header, a non-POST method, explicit credentials, or the response body. It is also the natural fallback when `sendBeacon` returns `false` and you want the `TypeError` to tell you why. ## Version note As of this writing, `keepalive` is supported across the evergreen browsers, but Firefox only shipped it in Firefox 133 (late 2024), well after Chrome and Safari. If you must support older Firefox builds, feature-detect it and fall back to `sendBeacon` — which has had much longer, broader support — rather than assuming the flag is honoured. An unsupported `keepalive` is silently ignored, not an error, so the request degrades to an ordinary fetch that teardown will cancel.