The Page Visibility API sees whether your tab is visible
A webpage does not become blind when you switch away from it. Modern browsers expose a small but useful signal called the Page Visibility API. It tells the page whether its document is visible or hidden, and it announces when that state changes.
That can sound more invasive than it is. The API cannot see which tab you opened next, read another page, or inspect the application covering the window. It receives a coarse status: this page is visible, or it is not. What the website does with that moment is where design, performance, and privacy meet.
What the Page Visibility API actually reports
The API adds two properties to the document. document.hidden returns true or false, while document.visibilityState normally returns visible or hidden. A visibilitychange event fires when the state changes.
According to the MDN Page Visibility API guide, a page can become hidden when you switch tabs, minimize the browser, or turn off the screen. The exact interpretation belongs to the browser. A partly visible foreground page is generally still visible.
The current WHATWG HTML standard defines visibility as a browser-managed state. It is deliberately broad. The signal describes the page's own presentation, not the identity of whatever has your attention instead.
Why well-designed sites use visibility
The most respectful uses save resources or keep an interface honest. A video player can pause when you leave its tab. A live dashboard can reduce network polling. An animation can stop consuming graphics power when no one can see it. A timed quiz can record that its page was hidden, while a chat app can wait to mark a message as read until the conversation is visible.
Browsers also throttle many background timers and suspend animation callbacks. The API lets developers cooperate with that lifecycle instead of discovering it through broken timers. It works especially well alongside the patterns described in our guide to how service workers change browser behavior.
The privacy question is about timing
A single hidden event says little. A sequence can reveal a pattern. A site may measure how quickly you return, how often you leave, whether you stayed for a video, or whether a checkout lost your attention. Analytics scripts can treat the transition to hidden as the likely end of a session and send a final event.
This does not expose your other tabs, but it can strengthen an engagement profile. It may help a publisher calculate active reading time rather than counting a page left open all afternoon. It can also feed pressure tactics: pause a countdown, change a title to call you back, or trigger a notification prompt after repeated exits.
The distinction resembles the Beacon API, which helps pages send small amounts of data as you leave. Page Visibility supplies the moment; another API may carry the measurement.
Visibility is not the same as focus or idleness
Visible does not mean actively read
A page can be visible while you look elsewhere, speak to someone, or use another window beside it. The API cannot prove that your eyes are on the content. It should never be treated as an attention detector.
Hidden does not identify the destination
The page learns that its content is no longer visible. It does not learn whether you opened email, checked a calendar, locked the computer, or moved to another browser tab. Any claim about the destination is an inference, not data supplied by this API.
Idle detection is a different capability
Idle Detection can combine absence of input with screen state and carries different privacy implications. We cover that distinction in our guide to the Idle Detection API. Page Visibility is narrower and does not require a permission prompt.
Why there is no permission prompt
The Page Visibility API is widely available and works without asking the user. Browsers treat it as a basic page-lifecycle signal. Pages already had partial clues from focus, blur, timer behavior, and unload events; a standard signal lets them respond more reliably and efficiently.
No prompt does not mean unlimited access. The browser supplies only the document's state. Same-origin rules, storage partitioning, background throttling, and private-mode separation still shape what a site can combine with that state.
Practical choices for readers
- Close tabs you no longer need instead of leaving sensitive sessions open indefinitely.
- Be cautious when a page changes its title, sound, or notifications to pull you back.
- Use tracker blocking to reduce third-party analytics that combine visibility with broader profiles.
- Review notification permissions separately; visibility does not grant permission to alert you later.
- Sign out of important services on shared devices, even if you use private browsing.
Private windows isolate some local state, but they do not stop a page from observing its own visibility while it is open. Our explanation of what private browsing does and does not protect is a useful companion.
A small signal can still deserve restraint
The Page Visibility API is good browser engineering. It helps pages pause work they cannot use and gives media a better sense of context. The respectful default is to use it for performance and accurate state, not as another lever for attention capture.
For readers, the key is proportion. A site can know when its own page leaves view. It cannot see where you went. That boundary is meaningful—and worth protecting as websites become more capable.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.