Browser-based instruments have quietly become good. Full synth engines, samplers, even hardware emulations now run in a tab with no installer and no licence file. The obvious question for anyone with an expressive controller: can you play them with MPE?
The answer is yes, more often than people expect — with two specific catches that decide everything.
MPE is just MIDI, and that's the good news
There is no "MPE mode" in the Web MIDI API, and there doesn't need to be. MPE isn't a new protocol; it's a convention layered on ordinary MIDI 1.0 channel voice messages — note-on, pitch bend, channel pressure and CC74, distributed across channels according to a zone configuration.
That means the browser doesn't have to support MPE at all. It just has to deliver raw MIDI messages faithfully, which Web MIDI does. Every byte your Seaboard, LinnStrument or Osmose sends arrives in the page exactly as sent.
The support question is therefore about the app, not the browser. A web instrument that reads event.data and handles channels correctly will play MPE. One that assumes everything arrives on channel 1 will give you a monophonic mess no matter how good your controller is.
Catch one: Safari doesn't do this
This is the hard limit. Safari does not implement the Web MIDI API, on macOS or iOS, primarily over browser-fingerprinting concerns — an enumerated list of a user's connected MIDI devices is quite identifying. As of 2026 there is no published roadmap for adding it.
Because every iOS browser is required to use Safari's engine, this means no Web MIDI anywhere on iPhone or iPad, regardless of which browser you install. An iPad with an MPE controller attached cannot drive a browser instrument. Native apps on iOS handle MPE fine; the web layer simply isn't available.
Where it does work, per caniuse.com/midi:
- Chrome 43 and later
- Edge 79 and later
- Opera 30 and later
- Firefox 108 and later
- Samsung Internet 4 and later
In practice: a desktop Chromium browser is the reliable choice, Firefox is a solid second, and anything Apple is out.
Catch two: the app has to understand zones
Assuming you're in a supporting browser, the remaining question is whether the instrument implements MPE's channel structure. Three things to look for.
Channel handling. In the standard Lower Zone layout, channel 1 is the master channel carrying global messages, and channels 2–16 are member channels, one note each. An app that ignores the incoming channel byte will stack every note's bend onto one voice.
Pitch bend range. MPE controllers default to ±48 semitones on member channels, not the MIDI default of ±2. The controller announces this via RPN 0 on the master channel. If the app doesn't read that RPN — or doesn't at least offer a manual setting — your slides will be dramatically undersized, which is the single most common symptom of a half-implemented MPE receiver.
CC74 as timbre. Vertical position on the key should be routed as a per-note modulation source, not treated as a global controller.
If a web instrument advertises MPE support, it has almost certainly handled all three. If it doesn't say, assume it hasn't.
Getting it running
The setup is short:
- Open the instrument in Chrome, Edge or Firefox, over HTTPS — Web MIDI requires a secure context and silently fails on plain
http://. - Grant the MIDI permission when the browser prompts. Chrome asks separately for SysEx access; some controllers need it for configuration handshakes, so allow it if the app requests it.
- Select your controller in the app's MIDI input list. Many controllers expose multiple ports — pick the one your DAW normally uses for MPE.
- Check the bend range in the app's settings and set it to 48 semitones if it wasn't detected automatically.
- Play a chord and bend one note. If the others move too, the app isn't reading channels, and no amount of configuration will fix that.
Building your own
For developers, the raw Web MIDI API is workable but low-level — you'll be parsing status bytes by hand. WEBMIDI.js wraps it in a far friendlier interface and handles channel-aware message routing, which is most of the MPE problem solved. Pair it with Tone.js for the synthesis side and a credible MPE-capable browser instrument is a weekend project rather than a research effort.
One design note worth taking seriously: allocate a voice per member channel, not per note number. MPE controllers rotate through channels deliberately so that overlapping notes of the same pitch stay separate. Keying your voice table off note number will produce baffling bugs the first time someone plays a legato repeat.
Is it worth it?
For performance, native software still wins on latency and stability. But for teaching, demonstrating, sharing a patch as a link, or letting someone try an expressive instrument without installing anything, the browser is genuinely useful — and the fact that MPE passes through untouched means the hard part was solved before the web got involved.
Just don't plan a workflow around it on an iPad.