Web MIDI Browser Support in 2026: Chrome, Firefox, Safari

Almost everything written about browser MIDI support is wrong, and it is wrong in a specific, predictable way: it was written in 2023, it says "Safari 16.4 shipped Web MIDI", and that never happened. Safari 16.4 shipped a lot of things. Web MIDI was not one of them. This post is the support picture as it actually stands, checked against caniuse, MDN and the vendor bug trackers on 14 October 2026 — plus the two permission changes that quietly broke a lot of working code.

Which browsers support the Web MIDI API right now?

Every Chromium-derived browser since Chrome 43, plus Firefox 108 and later on desktop — and nothing from Apple.

caniuse's Web MIDI table reports combined global support of about 79%. That number looks healthy until you notice what is missing from it, which is the entire Apple ecosystem and most of mobile.

The practical reading: if your users are on a desktop and not on a Mac using Safari, you have Web MIDI. If they are on a phone, assume you do not, unless you can confirm they are on Chrome for Android.

Does Safari support Web MIDI, and where did the "16.4" myth come from?

It does not, and the myth appears to be a blend of Safari 16.4's genuinely large feature drop with wishful thinking that got copied between blog posts until it looked like a fact.

caniuse lists every Safari version, desktop and mobile, as unsupported. MDN flags the whole API as "Limited availability — not Baseline because it does not work in some of the most widely-used browsers". There is no WebKit feature entry shipping it. If you have read otherwise, you have read a post that cited another post.

What does exist is userland. Web MIDI for Safari is an open-source Safari web extension that injects navigator.requestMIDIAccess into pages and backs it with CoreMIDI through the extension's native handler, behind its own per-site permission prompt. It is a port of the Chromium implementation's behaviour, and the caniuse entry carries a note about it. This matters for two reasons.

First: never sniff the user agent to decide whether to attempt MIDI. An extension-injected implementation is invisible to a UA string and perfectly visible to a feature detect. Second: do not assume the shape of the object you get is identical to Chrome's. Code defensively around manufacturer and version being null, which is good practice anyway.

// The only correct detection. Works for native and extension-injected
// implementations, on every engine, forever.
const hasWebMidi = typeof navigator !== 'undefined'
  && typeof navigator.requestMIDIAccess === 'function';

if (!hasWebMidi) {
  showFallbackUi('This browser cannot talk to MIDI devices.');
}

Why does Firefox make you install an add-on?

Because Mozilla shipped Web MIDI deliberately gated: the browser generates a site-permission add-on on the fly, and installing it is the permission grant.

The implementation landed through bug 1752906 and was enabled broadly in bug 1795025. Mozilla's stated position, recorded in bug 1795927, is that MIDI device enumeration is a fingerprinting surface and a silent grant was not acceptable; the add-on surfaces that cost to the user instead of hiding it.

Three consequences you will hit in development:

• The grant is scoped to the exact subdomain. Approving it on app.example.com does nothing for beta.example.com. Plan your staging hostnames accordingly.
• Localhost is exempt. You will develop happily and then hit the add-on prompt the first time you deploy. Test on a real hostname before you ship.
• The rejection looks like a denial, not a missing API. requestMIDIAccess exists; the promise rejects. Your feature-detect passes and your error path runs — which is exactly why you need both.

What changed in Chrome 124?

Chrome moved the entire Web MIDI API behind a permission prompt, where previously only sysex access prompted.

The Chrome team announced it on 16 April 2024, with the rollout beginning gradually in Chrome 124. The tracking bug is Chromium issue 40063295, titled "Gate the entire Web MIDI API surface behind a permissions prompt". The practical effect is that a page which used to enumerate ports instantly on load now shows a browser prompt, and a user who ignores it gets nothing.

If you wrote code before April 2024 and never revisited it, two things are probably broken. One: you call requestMIDIAccess() on page load, so the prompt fires before the user understands why, and they dismiss it. Two: you have no rejection handler, so the dismissal produces an unhandled promise rejection and a blank UI. Both are fixable in ten minutes.

// Request MIDI from an explicit user action, not on page load.
// The prompt then arrives with obvious context and gets approved far more often.
document.getElementById('connect').addEventListener('click', async () => {
  if (!('requestMIDIAccess' in navigator)) {
    return setStatus('unsupported');
  }
  try {
    const access = await navigator.requestMIDIAccess({ sysex: false });
    boot(access);
  } catch (err) {
    // 'SecurityError' is what you get when the prompt is dismissed or blocked.
    setStatus(err.name === 'SecurityError' ? 'denied' : 'error');
  }
});

You can also inspect the current grant without triggering a prompt, using the Permissions API. This is how you decide whether to show a "Connect MIDI" button or go straight in.

async function midiPermissionState(sysex = false) {
  if (!navigator.permissions) return 'unknown';
  try {
    const status = await navigator.permissions.query({ name: 'midi', sysex });
    return status.state;  // 'granted' | 'denied' | 'prompt'
  } catch {
    // Firefox does not expose 'midi' to the Permissions API.
    return 'unknown';
  }
}

Does Web MIDI require HTTPS?

Yes — it is a secure-context API, with the usual localhost exemption for development.

Secure contexts cover HTTPS origins, http://localhost, http://127.0.0.1 and file-free local development. Chromium went through a formal deprecate-and-remove cycle for Web MIDI on insecure origins, so a page served from a LAN IP over plain HTTP will find navigator.requestMIDIAccess simply absent.

This bites hardest in one specific scenario: testing a browser MIDI tool on a phone or a second laptop by typing the dev machine's LAN IP. That is an insecure origin and it will silently have no MIDI. Use a tunnelling tool with a real certificate, or run your dev server with a self-signed cert and accept it on the device.

How does Permissions Policy affect embedded Web MIDI?

A cross-origin iframe gets no MIDI unless the parent page explicitly delegates it.

The midi directive has a default allowlist of self. Same-origin frames inherit, cross-origin frames do not, and a policy denial cannot be overridden by the user — the Web MIDI spec is explicit that if the feature is disallowed by policy, no prompt is shown at all. If you publish an embeddable MIDI widget, the integration instructions must include the allow attribute or every embed will fail silently.

Is the Gamepad API better supported than Web MIDI?

Dramatically — around 97% global versus 79%, and critically it works on Safari and iOS where Web MIDI does not.

caniuse's Gamepad API table shows Chrome 21+, Edge 12+, Firefox 29+, Safari 10.1+, Opera 24+, iOS Safari 10.3+, Samsung Internet, Firefox for Android and Chrome for Android. The only meaningful gaps are Internet Explorer and Opera Mini.

That asymmetry shapes architecture. On an iPad, you can read a DualSense perfectly well through navigator.getGamepads() and drive Web Audio with it — you simply cannot emit MIDI to an external device from that same page. A browser gamepad instrument is viable almost everywhere. A browser gamepad-to-MIDI bridge is viable on desktop Chromium and desktop Firefox, and that is it. The polling mechanics are covered in the Gamepad API polling guide, and the combined build in the browser bridge guide.

What about WebHID?

WebHID is the narrowest of the three APIs by a wide margin: Chromium desktop only, roughly 30% of global traffic.

caniuse lists Chrome 89+, Edge 89+ and Opera 76+ on desktop. Firefox has not implemented it, Safari has not implemented it, and there is no mobile support anywhere. The specification itself lives at the Web Incubator Community Group rather than in a W3C working group, which is a fair summary of its standardisation status.

Despite that, WebHID is the only way to read devices the Gamepad API refuses to normalise — Joy-Cons being the canonical example. We cover the trade in the WebHID gamepad guide.

What should you actually target?

Build the Gamepad API path for everyone, layer Web MIDI on where it exists, and treat WebHID as a progressive enhancement for one or two specific devices.

A sensible capability ladder looks like this, in descending order of reach:

1. Gamepad API plus Web Audio. Works nearly everywhere, including iPad. A self-contained instrument in a tab. See the Web Audio gamepad instrument.
2. Gamepad API plus Web MIDI. Desktop Chromium and desktop Firefox. Drives hardware and DAWs.
3. WebHID for the awkward devices. Chromium desktop only. Joy-Cons, raw DualSense reports, rumble and LED writes.
4. A native bridge. Every OS, every host application, no tab required, no permission prompt. Universal Controller MIDI sits here.

Each rung up the ladder costs you reach and buys you capability. Most projects should implement rung one and two, detect for rung three, and link out to rung four rather than trying to fight the platform.

How do you keep this page from going stale?

Link to the data, do not transcribe it, and re-check the three caniuse pages before you make a support claim in any documentation.

The three canonical sources are caniuse.com/midi, caniuse.com/gamepad and caniuse.com/webhid, with MDN's compatibility tables as a cross-check. If you maintain a docs site, embed a feature-detect banner that reports the user's actual capability rather than publishing a table that will be wrong in eighteen months — which is exactly how the Safari 16.4 myth propagated in the first place.

FAQ

Does Safari support the Web MIDI API?

No. As of October 2026 no shipping version of Safari implements the Web MIDI API natively on macOS, iOS or iPadOS. caniuse lists every Safari version as unsupported. A third-party Safari web extension can inject the API on macOS, but that is userland, not WebKit.

Which browsers support Web MIDI in 2026?

Chrome 43 and later, Edge 79 and later, Opera 30 and later, Firefox 108 and later on desktop, plus Chrome for Android, Samsung Internet, Opera Mobile 80 and later and several Chromium-based Android browsers. caniuse puts combined global support at roughly 79 percent.

Why does Firefox ask me to install an add-on for Web MIDI?

Firefox gates Web MIDI behind a site-permission add-on that the browser generates on the fly. The install prompt is the permission prompt. The grant is scoped to the exact subdomain, and localhost is exempt so local development works without it.

Why does Chrome now prompt for MIDI when it never used to?

Chrome 124, rolling out from April 2024, moved the entire Web MIDI API behind a permission prompt. Previously only sysex access prompted. Chrome and Firefox now both require explicit user permission for any MIDI access.

Does Web MIDI work on iPhone or iPad?

Not in any browser. All iOS and iPadOS browsers are required to use WebKit, which has no Web MIDI implementation, so Chrome and Firefox on iOS inherit the gap. The Gamepad API does work on iOS Safari 10.3 and later.

Is the Gamepad API better supported than Web MIDI?

Considerably. caniuse puts Gamepad API global support at about 97 percent, including Safari 10.1 and later and iOS Safari 10.3 and later, versus roughly 79 percent for Web MIDI. You can read a controller in browsers that cannot send MIDI.

What about WebHID browser support?

WebHID is the narrowest of the three. caniuse shows Chrome and Edge 89 and later and Opera 76 and later on desktop only, around 30 percent global support. Firefox and Safari have not implemented it and there is no mobile support.

Does Web MIDI require HTTPS?

Yes. It is a secure-context API, so it is exposed on HTTPS origins and on http://localhost, but not on other plain HTTP origins. Chromium deprecated and removed Web MIDI on insecure origins.

The one-line version

Desktop Chromium and desktop Firefox can do browser MIDI; nothing Apple ships can. Test your own browser against reality in about four seconds by opening the Web MIDI visualiser — if the device picker populates, you have it.

When you need MIDI on a Mac in Safari, on an iPad, or simply available to every application without a tab open, the browser is the wrong layer. Universal Controller MIDI runs natively on macOS, Windows and Linux with no browser involved: free for one controller, one virtual port and three saved presets, AUD $89 one-time for Pro. The deeper API reference is in the complete Web MIDI guide.