← Blog 6 min read

Beacon API: What Pages Send as You Leave

Beacon API: What Pages Send as You Leave

Closing a tab does not always end a page's network activity immediately. A website can ask the browser to queue a small data transfer just as the page moves into the background. The web feature designed for this job is the Beacon API, usually called through navigator.sendBeacon().

Beacons are commonly used for analytics and diagnostics: recording that a session ended, saving a final progress event, or reporting an error without delaying the next page. The same reliability that makes the API useful also deserves privacy attention. A send can happen at the moment when the user reasonably feels finished with the page.

What sendBeacon actually does

A page provides a destination URL and an optional small payload. The browser attempts to queue that data for asynchronous transfer and returns true if it accepted the item into its queue. According to MDN's sendBeacon documentation, acceptance does not prove that the server ultimately received the data.

The request is designed not to block navigation. Older analytics code sometimes delayed unloading a page or used synchronous requests to improve the chance that a final event arrived. Those techniques made the browser feel slow. A beacon lets the browser schedule a compact transmission while the user continues.

Why pages send data when they become hidden

A page cannot depend on a traditional closing event. Mobile users may switch apps and later terminate the browser. A laptop may suspend. Browsers may preserve a page in the back-forward cache rather than unload it. MDN recommends using the visibilitychange event and sending when the document becomes hidden, because that transition is more dependable than waiting for unload.

The W3C Beacon specification says browsers should schedule queued beacon requests promptly when a document's visibility changes to hidden. That may happen when you switch tabs, minimize the browser, navigate elsewhere, or move to another application. Hidden does not necessarily mean destroyed.

What a beacon can contain

The API can carry a string, form data, URL-encoded values, a blob, or other supported body formats. A site decides what fields to put inside. Examples include a page identifier, session duration, the last completed step, playback position, performance measurements, or error details.

The browser places limits on queued data so the API remains suitable for quick delivery rather than large uploads. MDN documents a shared queued-data ceiling of 64 KiB in common implementations. For larger transfers, custom methods, or reading a response, developers generally use fetch() instead.

A beacon is not automatically anonymous. The receiving server still observes network information such as the public IP address and normal request context. Cookies may accompany a request when browser credential and same-origin rules allow them. The privacy impact therefore depends more on the destination and payload than on the small size.

Is a beacon a tracker?

The API is a delivery mechanism, not a purpose. A first-party application can use it to save a legitimate state change. A publisher can measure whether readers reached the end of an article. An advertising or analytics script can use it to report behavior to a third party.

That distinction is similar to ordinary fetch() requests, pixels, and form submissions. Beacons are notable because the browser tries to deliver them without making the user wait, including around backgrounding and navigation. The W3C specification explicitly recognizes that delivered data may contain sensitive information about activity on a page.

How beacon requests differ from link pings

The HTML ping attribute is tied to following a hyperlink. It notifies named endpoints that a specific link was activated. sendBeacon() is a JavaScript API that a page can call for many kinds of events, whether or not a link was clicked.

Our guide to link auditing and ping requests explains that narrow click-reporting mechanism. Both can create short background requests, but blocking one does not guarantee that the other is blocked.

What the browser still controls

The browser decides whether it can queue the data, when to transmit it, and how request security rules apply. Cross-origin beacons remain subject to Fetch and CORS behavior. Certain payload content types can require the receiving server to approve a preflight request.

The Beacon API does not expose a response callback. Page code cannot use it as a quiet substitute for a full conversation with a server. It also cannot demand unlimited storage or hold the browser open indefinitely. These constraints protect performance, though they do not determine whether the data collection is appropriate.

Does private browsing stop beacons?

Private mode primarily changes how browsing state is retained after the session. It is not a promise that websites cannot make network requests. The Beacon specification advises browsers not to disable the API merely because private browsing is active, both to avoid breaking applications and to avoid revealing the private-mode state.

Private browsing may isolate or clear cookies, but a server can still receive a beacon during the session. Read what private browsing does and does not hide for the larger boundary.

Practical protections

Block known tracking endpoints

Request-level tracker blocking can stop connections to recognized analytics and advertising domains regardless of whether the page used sendBeacon(), fetch(), an image, or another API. Our tracker-blocking guide explains why the destination often matters more than the JavaScript method.

Limit unnecessary third-party scripts

A script cannot send events if it never loads. Use a browser with sensible protections, remove extensions you do not trust, and be cautious with sites that embed many outside services. Content blocking can reduce both visible clutter and invisible reporting paths.

Keep expectations measured

Not every background request is surveillance, and blocking every beacon can break session saving or diagnostics. Strong privacy tools distinguish known tracking infrastructure from useful first-party behavior and give users a consistent policy.

The page may finish before the request does

The Beacon API fixes a genuine performance problem: small, important sends should not make navigation feel stuck. Its privacy lesson is equally simple. Leaving a page does not guarantee that all its queued communication has stopped. The best protection is visibility at the browser layer, careful control of third-party destinations, and data collection that remains proportionate to the service being provided.

Browse with more intention

Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.

Download Noorani