navigator.audioSession returns the document’s AudioSession object. Set type to tell the platform whether you are playing music, showing a short sound, or running a call. Learn feature detection, common types, five examples, and try-it labs.
01
Kind
Read-only property
02
Returns
AudioSession
03
Status
Experimental
04
Key knob
.type
05
Baseline
Not yet
06
Detect
in navigator
Fundamentals
Introduction
Phones and desktops constantly mix sounds: music, maps, notifications, and video calls. The Audio Session API lets a web page declare the kind of audio it produces so the OS can pause, duck, or mix other audio appropriately.
Your entry point is navigator.audioSession. That property is read-only and returns an AudioSession object. You usually set navigator.audioSession.type before starting playback or a call.
💡
Optional enhancement
Missing support does not break media. Without audioSession, browsers still play audio — you just cannot send a session-type hint.
Concept
Understanding the audioSession Property
Think of audioSession as a handle to policy settings for this document’s audio. The most important setting today is type.
navigator.audioSession is read-only and returns an AudioSession.
AudioSession.type is readable and writable when the API exists.
Types describe intent: playback, transient sounds, ambient mix, or play-and-record.
Always feature-detect — the API is experimental and not Baseline.
Foundation
📝 Syntax
General form of the property:
JavaScript
navigator.audioSession
Value
An AudioSession object for the current document.
Common type values (MDN)
"auto" — default; user agent chooses.
"playback" — music / video / podcasts (often exclusive vs other playback).
"transient" — short sounds; may duck other audio.
"transient-solo" — exclusive prompts (for example directions).
"ambient" — mixes with other audio.
"play-and-record" — calls / mic + playback.
Common patterns
JavaScript
if ("audioSession" in navigator) {
navigator.audioSession.type = "play-and-record";
}
// Then start media / getUserMedia as usual
const stream = await navigator.mediaDevices.getUserMedia({
audio: true,
video: true
});
Cheat Sheet
⚡ Quick Reference
Goal
Code
Feature detect
"audioSession" in navigator
Get the session
navigator.audioSession
Read type
navigator.audioSession.type
Music / video
type = "playback"
Notification beep
type = "transient"
Video call
type = "play-and-record"
Snapshot
🔍 At a Glance
Four facts to remember about audioSession.
Returns
AudioSession
Per document
Status
experimental
Not Baseline
Control
.type
Set intent
Missing?
OK
Audio still works
Compare
📋 Common type values
Type
Typical use
Platform behavior (approx.)
auto
Default
UA decides from APIs you use
playback
Music, video, podcasts
May pause other playback audio
transient
Notifications
Often ducks other audio
transient-solo
Voice prompts / directions
Exclusive; others may pause
ambient
Background mix
Mixes with other audio
play-and-record
Calls / mic + media
Simultaneous capture + playback
Hands-On
Examples Gallery
Examples follow MDN Navigator.audioSession patterns with safe feature detection. Use View Output or Try It Yourself for each case.
📚 Getting Started
Detect support and read the current type safely.
Example 1 — Feature Detection
Check whether audioSession exists before using it.
skipped (no audioSession)
(or "set type=playback")
How It Works
On supporting platforms, "playback" can pause other playback audio while your media runs.
Example 4 — "play-and-record" for Calls
Set the type before starting camera/mic for a conference-style flow.
JavaScript
async function startCallPreview() {
if ("audioSession" in navigator) {
navigator.audioSession.type = "play-and-record";
}
// Demo only logs intent — real apps call getUserMedia next
return "ready for getUserMedia (audio+video)";
}
startCallPreview().then(console.log);
navigator.audioSession is Experimental and not Baseline. Many widely used browsers do not expose it yet. Feature-detect and treat it as progressive enhancement.
✓ Experimental · Not Baseline
Navigator.audioSession
Useful on supporting platforms for audio policy hints. Always detect before reading or setting type.
LimitedNot Baseline
Google ChromeCheck current MDN compat — limited / evolving
Limited
Mozilla FirefoxCheck current MDN compat — may be unavailable
Limited
Apple SafariRelated Audio Session work may appear on some platforms
Limited
Microsoft EdgeFollow Chromium Audio Session status
Limited
OperaFollow Chromium status
Limited
Internet ExplorerNo Audio Session API
Unavailable
audioSessionLimited
Bottom line: Use audioSession when available to declare playback vs call intent. Never require it for core media features.
Wrap Up
Conclusion
navigator.audioSession is the experimental entry point to the Audio Session API. Feature-detect it, set type for playback or calls when available, and keep your media code working without it.
Experimental AudioSession handle — set type, detect first.
5
Core concepts
🎧01
Returns
AudioSession
API
🔧02
type
set intent
Control
🧪03
Status
experimental
Caution
🔍04
Detect
in navigator
Safety
📞05
Calls
play-and-record
Pattern
❓ Frequently Asked Questions
It is a read-only Navigator property that returns the AudioSession object for the current document. You use that object to declare how your page's audio should interact with other audio on the device.
Yes. MDN marks it Experimental and not Baseline. Always feature-detect before using it, and check the compatibility table before shipping to production.
Assign navigator.audioSession.type to a string such as "playback", "transient", "ambient", or "play-and-record". The default is "auto".
For video calls or any flow that needs simultaneous playback and microphone capture. Set the type before starting getUserMedia or remote media when possible.
No. The property is read-only and returns an AudioSession. You change behavior by setting AudioSession.type on that object.
Your audio still works with normal media APIs. The platform simply will not receive your Audio Session type hint. Feature-detect and treat the API as an optional enhancement.
Did you know?
On some mobile platforms, "play-and-record" can influence routing (for example earpiece vs loudspeaker) during a call — that is why declaring session type before getUserMedia matters when the API is available.