navigator.audioSession lets a page declare its audio type and see an interrupted state. What that reveals about your device, and where the limits are.
A web page that is playing audio can find out when something outside the browser takes the audio stack away from it — an incoming phone call, for example, or another app grabbing exclusive control of audio. It needs no permission prompt and no microphone access to do so. That is a side effect of an API built for a sensible reason: telling the operating system what kind of audio a page is making. This post covers what the Audio Session API exposes, what it cannot tell a page, and why it belongs in the same family as other "adaptation APIs" that double as passive observation.
Key Takeaways
navigator.audioSessionlets a page declare its audio category through atypeproperty:auto,playback,transient,transient-solo,ambient, orplay-and-record. The operating system uses it to decide whether to duck, pause, or mix other audio.- The session also has a
state—active,inactive, orinterrupted— and fires astatechangeevent when it changes. interruptedis raised by things outside the browser, such as a phone call or another app taking audio focus. The page learns that something took priority, and when — not who called or what the interruption was.- Support differs by engine. WebKit shipped a subset of the API in Safari 16.4, MDN still marks it experimental with limited availability, and the platform decides what counts as an interruption, so the API's presence and behaviour is also a coarse engine signal.
- There is no setting to turn it off. The behaviour is inherent to having audio on the page, so the realistic defence is awareness plus general anti-fingerprinting hygiene.
What the Audio Session API Is For
Before this API, a browser had to guess how a page's audio should interact with everything else on the device. A video-call page, a podcast player, and a page that plays a short notification chime all look similar from the outside, yet a phone should treat them very differently: the call should take priority and mute other apps, the podcast should pause when a call arrives, and the chime should simply duck other audio for a moment.
AudioSession fixes that by letting the page say what it is doing. The type property takes one of these values:
| Type | Intended use |
|---|---|
auto | Let the browser pick based on what is playing |
playback | Music, video, podcasts — audio the user came for |
transient | Short sounds such as a notification; other audio is ducked |
transient-solo | Short sounds that should silence everything else briefly |
ambient | Background sound that can mix with other apps |
play-and-record | Two-way audio, such as calls |
The W3C specification is called "Audio Session", and WebKit announced support for a subset of it in the Safari 16.4 release notes. Declaring a type is the legitimate half of the story, and it is a good design: it gives the platform information instead of making it infer intent.
The Other Half: Session State
The same object reports where the session currently stands:
if ("audioSession" in navigator) {
console.log(navigator.audioSession.type); // e.g. "playback"
console.log(navigator.audioSession.state); // "active", "inactive" or "interrupted"
}
Three states are defined. active means the page is playing or recording audio, inactive (the default) means it is doing neither, and interrupted means the platform has temporarily suspended a session that was active. A statechange event fires on transitions, so a page does not need to poll. While the session is interrupted, the browser itself pauses the page's media elements, suspends its AudioContexts and mutes its microphone tracks, then resumes them when the state returns to active.
interrupted is the one with privacy weight. MDN's own examples of what causes it are an incoming phone call and another application taking exclusive control of audio. The related Web Audio property AudioContext.state uses the same word, defined as an interruption by "an occurrence outside the control of the web app", and MDN adds there that how the interrupted state is triggered may vary between browsers. The exact set of triggers is up to the platform and the browser, which is why it varies.
Why This Is a Privacy Story
Most signals about what the user is doing on their device are either permission-gated or simply unavailable to the web. Whether you are on a call is not something a page is meant to know. The Audio Session API leaks a faint version of it as a by-product of playing sound.
It is worth being precise about the limits, because this is easy to overstate:
- A page cannot learn who called, or what the interruption was. It sees a state change, not a cause.
- It only works while the page has an audio session. A page with no audio has nothing to interrupt.
- One event is weak evidence. A phone call and another app grabbing audio focus can look the same.
What remains is a behavioural timeline. Because the page also sees the return to active, it can time each interruption. Repeated interruptions, their timing, and how long the session stays interrupted add up to a record of when a device was busy with something else. That is not an identifier by itself, but it is the kind of low-grade, no-prompt signal that analytics and anti-fraud systems like to collect, and one that a user would not expect a page to see.
The Quieter Signal: Feature Detection
There is a second, more conventional leak. Whether navigator.audioSession exists at all, and how the interrupted state is triggered, depend on the engine. WebKit shipped a subset in Safari 16.4, MDN flags the API as experimental and not Baseline, and for the closely related AudioContext.state it states explicitly that the way interruption is triggered may differ between browsers. That divergence is exactly the pattern covered in engine version and feature detection: a capability that exists in one engine and not another narrows down which browser and OS you are running, without reading a single user-agent string.
BrowserInsight's kernel check works this way for Chromium. Its feature matrix tests for audio APIs such as AudioContext.setSinkId() to place a browser on the version timeline. To be clear about scope: the site does not probe navigator.audioSession, AudioSession.state or AudioContext.state, and no tool here reports call or interruption events. setSinkId() is simply a concrete example of audio API presence acting as an engine signal.
The Same Pattern as Other Device-State APIs
None of this is unique to audio. The recurring lesson is that APIs designed so pages can adapt to the device double as passive observation of it:
- The Battery Status API gave pages charge level and charging state with no prompt, and was later pulled from Firefox and never shipped in WebKit.
- The Network Information API exposed connection type and estimates, with a Chromium-leaning footprint.
- Media devices enumeration reveals which cameras and microphones are attached.
- Device sensors expose motion and orientation readings.
In each case the original purpose is real. The privacy cost arrives from the combination of no permission prompt, continuous updates, and uneven implementation across browsers.
Why Mobile Is Where It Bites
Interruptions are common and meaningful on a phone, and rare on a desktop. Calls and other apps competing for audio focus happen constantly on mobile, so the signal is both richer and more distinctive there. That is why this post sits in the mobile cluster: the same API on a desktop browser mostly sits quiet. For the wider picture of how phones differ, see mobile browser fingerprinting.
What You Can Actually Do
Honestly, very little. There is no toggle for the Audio Session API, and the behaviour comes from having audio on the page at all. Pages you have not given audio to have nothing to observe. Beyond that, the realistic answer is the general posture that applies to every minor signal:
- Block or limit scripts you do not need, with a content-blocking extension.
- Prefer a browser with tighter anti-fingerprinting defaults.
- Check what your own browser exposes with the fingerprint check, and read what a fingerprint is for the bigger picture.
Inconsistencies matter too: a profile claiming to be one platform while exposing the API surface of another is the kind of mismatch covered in fingerprint consistency.
Frequently Asked Questions
Can a website tell that I am on a phone call?
Not directly. A page that is playing audio can see its audio session become interrupted, which a call can cause. It can time how long the interruption lasted, but it cannot tell who called, or whether the cause was a call or something else, such as another app taking over audio.
Does the Audio Session API need a permission?
No. It is a property of navigator, and reading its type and state does not trigger a prompt. That is a large part of why it matters for privacy.
Which browsers support it?
WebKit shipped a subset in Safari 16.4. MDN marks the API as experimental with limited availability, so check the current compatibility table on the MDN page rather than assuming.
Can I turn it off?
There is no setting. Not playing audio on a page leaves nothing to interrupt, and blocking unneeded scripts limits who is watching.
Conclusion
The Audio Session API is a reasonable answer to a real problem: operating systems should know what kind of audio a page is making. Its interrupted state is the unintended extra. It lets a page notice that something outside the browser took priority, without a prompt and without learning the cause. The signal is weak by itself, richer on phones than on desktops, and sits alongside the battery, network and sensor APIs as a reminder that adaptation features and observation features are often the same feature.
Recommended Reading:
