Summary

  • Web MIDI gives a web application access to MIDI input and output ports: it can hear a keyboard, address a synthesizer or talk to a lighting controller. MIDI carries event messages, not the sound coming out of the speakers.
  • The browser's door needed more than a simple open/closed sign. Device identities can reveal a setup, and System Exclusive messages can address a device in manufacturer-specific ways. The 2026 W3C draft gives SysEx a stronger permission and limits which embedded pages may ask.

The keyboard is old enough to vote. Its owner has kept it because the knobs feel right and the sound has character; neither virtue is improved by forcing a software installer onto the laptop. A browser-based sequencer could take a note from that keyboard and send another to the synthesizer. It could also let a controller's faders run a web app or cue stage lights. The 2012 W3C draft imagined this low-level bridge. It made a point that still saves arguments at rehearsals: MIDI sends instructions about notes, controllers, tempo and cues. It does not carry the audio itself. The synth makes the sound. The browser may be the conductor, but the orchestra remains plugged into the wall.

That distinction kept the API usefully modest. A browser does not need to know whether a knob means “more vibrato,” “dim the lights” or “please make the bass player nervous.” It needs an input, an output and a way to move messages between them. The musician and the web application supply meaning. One protocol can serve a piano, a drum machine and a theatre lighting desk without a committee teaching the browser music theory.

The first draft was less modest about the information a port could disclose. It proposed a fingerprint property for a MIDI port, stable enough for an app to find the same instrument after a restart. That is convenient when a studio has several identically shaped boxes. It is also a clue about the user's hardware. Manufacturer, port name and version were visible alongside it. The draft itself raised privacy and security questions around enumerating interfaces and around System Exclusive, or SysEx, messages. The useful address book and the revealing address book were the same book.

SysEx is where the guest list became serious. A note-on message asks an instrument to play; a System Exclusive message can speak a vendor's private dialect. It may retrieve or change a patch, configuration or other device-specific data. A page asking to send ordinary notes and a page asking to enter this back room are making different requests. The 2015 W3C draft made that distinction explicit with requestMIDIAccess({sysex:true}). If the extra capability was denied, that request could fail. The musicians still got their notes; the equipment room acquired its own key.

It took more than a single permissions prompt to draw the line. A web page can be embedded inside another page; a device can disappear during a session; an output message can be scheduled for a precise time rather than fired when JavaScript happens to wake up. These are studio problems wearing browser clothes. Access to input and output ports has to be discoverable and revocable in practice, while message timing must remain useful to a player who can hear a late beat immediately. The API describes ports, connection state and timestamped output, leaving the musical interpretation with the application.

The 20 October 2026 W3C draft draws a more legible door. It integrates a permission named midi; {sysex: true} is stronger than ordinary MIDI access. Without that stronger capability, SysEx sent to a port raises an exception and incoming SysEx is masked. It places requestMIDIAccess() in secure contexts. Its Permissions Policy feature is midi, with a default allowlist of 'self': an embedded stranger does not inherit a studio key simply by appearing in the frame. The draft's security discussion also examines what device-specific messages could do to vulnerable hardware. It is an analysis of a possible path, not a report that every synthesizer is waiting to be sabotaged.

The W3C publication history tells its own slow rhythm: public drafts in 2012, 2013, 2015, then a run in 2024, 2025 and 2026. A publication date is a standards milestone, not a birthday for every browser implementation. The enduring problem is simpler than that chronology. The web wants the musician's physical tools without turning every page into a backstage pass.

Back at the desk, the old keyboard sends middle C. The browser catches the message, passes it to a web app and perhaps returns a note to the synth. Nothing needs to pretend the instrument has become a website. The permission latch sits where it belongs: between a useful conversation with hardware and a page that wants to know far too much about the room.