Three APIs, different support
A native device picker, media-element routing and Web Audio routing are separate capabilities.
Compare output selection →Browser Audio Compatibility Report
Output selection, microphone access, sample rates and surround sound across desktop and mobile browsers. Based on versioned compatibility data, browser documentation and a scoped public issue report.
Three distinctions that change the result
A rate belongs to a stage
A context reading describes processing in the browser, not an independently measured sound-card format.
Understand the readings →Capacity needs confirmation
Reported channel capacity cannot tell you which physical speaker actually played.
Check the evidence limits →Compatibility at a glance
Browser audio compatibility depends on the particular operation. A browser may capture a microphone and play sound while lacking a page-level output picker. For generated tones, check Web Audio output routing separately from audio/video element routing.
The following tables summarize documented API availability in MDN Browser Compatibility Data 8.1.0, checked September 7, 2026. A version is the recorded introduction version, not a browser version we tested. “Not supported” means BCD records no support in this snapshot. “Unverified” means this report has no physical-device result.
Desktop rows cover BCD's desktop browser entries, used for Windows/macOS browser comparisons; BCD does not provide a separate result for every operating-system build. Safari refers to macOS. Android and Safari on iOS are listed separately. Other iOS browser brands, embedded WebViews and managed enterprise configurations are outside this matrix.
| Browser scope | Web Audio output switch | Audio/video output switch |
|---|---|---|
| Chrome desktop | Supported from 110 | Supported from 49 |
| Edge desktop | Supported from 110 | Supported from 17 |
| Firefox desktop | Not supported | Supported from 116 |
| Safari macOS | Not supported | Supported from 18.4 |
| Chrome Android | Supported from 110* | Not supported |
| Firefox Android | Not supported | Not supported |
| Safari iOS | Not supported | Supported from 18.4 |
Sources: Web Audio entries, media-element entries. *Chrome Android's Web Audio entry inherits Chrome's support in BCD; this is not confirmation that every Android route can be selected. Its media-element entry explicitly records an Android limitation. Edge's historical media-element version 17 refers to legacy Edge; its Web Audio entry mirrors Chromium.
| Browser scope | Native output picker | Modern microphone API |
|---|---|---|
| Chrome desktop / Android | Not supported | Available; permission required |
| Edge desktop | Not supported | Available; permission required |
| Firefox desktop | Supported from 116 | Available; permission required |
| Firefox Android | Not supported | Available; permission required |
| Safari macOS / iOS | Not supported | Available; permission required |
Source: MediaDevices entries. These are separate APIs: a missing native picker does not mean the browser cannot play through the operating system's selected output. API availability also does not guarantee permission, device access or successful playback.
Physical 5.1/7.1 output remains unverified for every browser/system combination in this report. See the surround-sound evidence requirements before treating channel support as a hardware result.
Can you choose a speaker inside the browser?
There are three distinct operations: choosing an allowed device, routing an audio/video element, and routing a Web Audio graph. A working implementation of one does not establish support for the others. The compatibility tables above keep those operations separate.
- Web Audio:
AudioContext.setSinkId()routes generated or processed audio. Chrome's implementation was introduced in version 110. Non-default devices depend on access to an allowed device ID. Chrome implementation notes - Audio/video elements:
HTMLMediaElement.setSinkId()targets a media element. Its browser support differs from Web Audio, especially on Firefox, Safari and Android. Versioned compatibility entries - Native picker:
navigator.mediaDevices.selectAudioOutput()asks the user to choose and authorize an output. It requires a secure context, a recent user interaction, and an allowed speaker-selection policy. The selected device still has to be used by the relevant playback API. Permission requirements
If a page does not offer an output selector, choose the device in system sound settings and repeat the speaker test or headphone test. That is a practical fallback, not evidence that every site implements an in-page selector. Device lists can omit non-default devices or identifying labels until access has been granted. Device enumeration
Historical reported exception: WebKit issue 320087 was reported July 23, 2026 on an iPhone 15 running iOS 26.5. A media element's output-switch promise resolved while a single-track remote WebRTC stream stayed on the old output; two tracks behaved differently. The issue is marked FIXED, with WebKit commit 318149 landing July 29. The linked record does not identify the shipping Safari version containing the fix. We have not reproduced the issue; it is not a general Safari failure claim or a test of this site's generated tones. Original report, fix and reproduction details
Why can microphone access fail in a supported browser?
Microphone API support does not grant microphone access. A deployed page needs HTTPS, user authorization and permission from the operating system. Embedded pages also depend on the parent page's permissions policy. A request can remain pending if the user leaves the prompt unanswered. Capture requirements
| Observation | What to check next |
|---|---|
| NotAllowedError | Site permission, system microphone access, secure context and embedding policy. The error alone does not identify which gate failed. |
| NotFoundError | Whether an input matching the request is connected and available. |
| NotReadableError | Whether the system or device can start capture; permission alone may not resolve this. |
| OverconstrainedError | Relax the requested constraints and inspect the reported failing constraint. |
Source: getUserMedia errors. These are documented error categories, not measured failure rates.
For Windows, macOS, Android and iOS, check both site-level and system-level access. Permission prompts and persistence can differ by release, browser mode and device policy; this report does not claim a fixed prompt lifetime. In the microphone test, start explicitly, speak at a normal level and confirm the selected input. A missing label is not proof that no microphone exists. Device-list restrictions
Output playback is a separate permission and policy question. Browsers may suspend or block audible playback until the user interacts with the page; granting microphone access should not be treated as a universal autoplay bypass. Autoplay guidance
Does 48 kHz mean the hardware runs at 48 kHz?
A browser's reported sample rate describes a particular stage of the audio path. It does not certify an end-to-end, bit-perfect hardware route. Record which value you are reading before comparing two results.
| Value | What it describes |
|---|---|
| Requested AudioContext sampleRate | The rate requested when creating the graph; an unsupported rate can cause NotSupportedError. |
| AudioContext.sampleRate | The graph's actual processing rate. Without an explicit request, the output device's preferred rate is used by default. |
| Audio track getSettings().sampleRate | The capture track's reported rate, where this setting is exposed. |
| Sound-device or system format | A separate configuration outside these JavaScript readings; no hardware measurement is included here. |
Sources: AudioContext options, capture-track setting. The track setting has limited browser availability; an absent value means unknown, not zero.
Web Audio specifies resampling when a media stream's rate differs from its destination context's rate. A matching number at one stage therefore cannot rule out conversion elsewhere. Web Audio specification
For a useful comparison, keep the same device and route, record the context rate, record the input-track rate if available, and note any requested constraints. Our 44.1 vs 48 kHz guide explains the distinction; the spectrum analyzer provides a relative frequency view, not calibrated hardware response.
Can browsers output discrete 5.1 or 7.1 audio?
Web Audio can represent multichannel signals, but discrete playback also depends on the destination, operating-system routing, connection and physical receiver or speakers. A browser-wide “5.1 supported” badge would conceal those conditions. This report has no end-to-end physical validation for any listed combination.
The destination's maxChannelCount reports an upper channel limit. It is not a count of connected, audible speakers. The configured channelCount is a separate value. Destination documentation
Web Audio defines speaker mixing for mono, stereo, quad and 5.1, and discrete channel handling for other routing needs. Down-mixing can make several source channels audible through two speakers. An eight-channel graph alone does not identify a physical 7.1 speaker layout. Mixing specification
| Evidence | What it establishes |
|---|---|
| API and destination properties | The browser exposes an interface and reports a channel capacity. |
| Six or eight digital signals | The application can construct a multichannel signal path. |
| A named speaker audibly responds in isolation | A physical channel observation for that exact route and setup. |
| Every position repeats correctly with the setup recorded | Stronger evidence of end-to-end routing; not a result supplied by this report. |
Our recommended verification record includes browser and OS versions, sound device, connection type, system speaker layout, processing effects, destination properties and a per-speaker observation. Retest after changing any part of that chain. This is the report's proposed verification method, not a published test dataset.
The 5.1/7.1 surround test distinguishes reported multichannel capability from a stereo fallback. Confirm physical positions yourself before concluding that discrete routing works. Start quietly; a successful test is not a loudness or hearing assessment.
Common compatibility questions
Which browser should I use for a generated-tone output selector?
In this BCD snapshot, Chrome and Chromium-based Edge expose AudioContext output switching; Firefox and Safari do not. Choose based on the operation you need, then verify the actual device. This is a documented feature comparison, not an overall browser ranking. Web Audio data
Does missing output selection mean the sound test cannot work?
No. Default-route playback and page-controlled output switching are different capabilities. Set the intended system output, press Play and confirm the physical sound. If playback remains silent, follow the no-sound procedure.
Can this report prove a particular USB headset or HDMI receiver works?
No. Its sources describe browser APIs, rules and a scoped public issue. It does not contain device-specific listening tests. The sound diagnosis workflow can help you record symptoms and choose a retest, but it cannot replace that physical evidence.
Does a passed browser conformance test prove audible output?
Only the assertions and environment recorded for that run are established. Automated tests may use simulated devices or offline processing. We include no WPT pass percentages in this edition because we have not selected and audited a reproducible set of run results.
Research method and evidence limits
This is a desk-research report prepared by the Online Sound Test Team. We inspected the three versioned BCD files linked below, cross-checked routing with Chrome's implementation documentation, and used MDN and W3C for permission, rate and channel semantics. All sources were consulted on September 7, 2026.
Selection: The matrix covers the operations most relevant to this site's output tests and microphone tools. It uses BCD 8.1.0, rather than a moving “latest” table. Mirror entries inherit the upstream browser record; explicit mobile overrides take priority. Support versions describe APIs, not tested OS/device combinations.
Evidence labels: Compatibility tables are documented support. W3C rules are specified behavior. The WebKit example is a third-party reported issue. Physical routing and device-specific acoustic results are unverified. We conducted no new cross-platform hardware tests for this edition and claim no public conformance-run results.
Conflicts and changes: A reproducible issue can qualify a support entry without negating the entire API. We retain its narrow scenario and link the original record. Later data or fixes require a reviewed update; they do not silently change this snapshot. Absence of a bug report is not proof of reliability.
What remains unknown: Physical 5.1/7.1 routing, sound-card native rates, device-specific latency, Bluetooth profile behavior, exact permission persistence and all browser/OS build combinations. No reliability scores or measured success rates are assigned.
For our signal-generation and local-processing rules, see Test Methodology. To suggest a correction, contact us with the affected claim, browser/OS version and a primary source or reproducible example.
Sources and provenance
Versioned BCD links preserve the matrix baseline. Documentation and issue pages may change after the source-check date. Each note identifies the claim supported.
- MDN BCD 8.1.0 — AudioContext
Web Audio output switching; Firefox and Safari absence; Chromium support inherited through BCD mirror entries.
- MDN BCD 8.1.0 — HTMLMediaElement
Media-element output switching, including explicit Android exceptions and Safari 18.4 support.
- MDN BCD 8.1.0 — MediaDevices
Output picker and modern microphone-capture API support.
- Chrome Developers — Change the destination output device in Web Audio
Chrome 110 introduction, device access and Web Audio routing examples.
- MDN — selectAudioOutput()
User activation, output permission and speaker-selection policy.
- MDN — getUserMedia()
Secure context, permission, embedding requirements and capture errors.
- MDN — enumerateDevices()
Why device lists and labels depend on permission and document state.
- MDN — AudioContext() options
Preferred output rate, requested sample rate and unsupported-rate errors.
- MDN — MediaTrackSettings.sampleRate
The capture track's reported sample rate and limited availability.
- MDN — AudioDestinationNode.maxChannelCount
The destination's reported channel limit, which is separate from physical speaker verification.
- W3C — Web Audio API
Resampling and speaker/discrete channel mixing rules. A specification describes intended behavior, not a device test result.
- MDN — Autoplay guide for media and Web Audio
Why playback can wait for a user gesture even when the audio API is present.
- WebKit issue 320087 — iOS WebRTC routing bug, resolved in WebKit
Reported on iPhone 15 / iOS 26.5; marked FIXED after a July 29, 2026 WebKit commit. The record does not identify a shipping Safari fix version. Not independently reproduced here.
Updates and citation
— First edition. Added an output/API matrix using BCD 8.1.0, permission guidance, sample-rate distinctions and physical surround-sound evidence limits.
Cite this report
Online Sound Test Team. Browser Audio Compatibility Report. September 7, 2026. MDN BCD 8.1.0 snapshot.
https://onlinesoundtest.com/browser-audio-compatibility
Link directly to a section when discussing a specific claim, and include its conditions and source-check date. Source material remains attributed to its original publishers. Send a correction.