MIDI Test Guide

A reference for the DeskTest.net MIDI Test. Covers how it detects MIDI devices and decodes live note, control-change, pitch-bend, and program-change input through the browser's Web MIDI API, how to read the verdict, and what to do when a device is not detected, access is blocked, or the browser has no Web MIDI at all.

Open the MIDI Test →

What does the MIDI Test check?

The tool drives the browser's Web MIDI API. It feature-detects navigator.requestMIDIAccess, requests access to your MIDI devices (without SysEx), lists every connected input and output port, then attaches a listener to each input and decodes the messages you play in real time. No plugin, no extension, no upload. It runs in two steps:

1. Web MIDI is supported and access is granted. Feature-detects the API, then calls requestMIDIAccess({ sysex: false }). The browser may show a one-time permission prompt. On success the tool lists your MIDI inputs (keyboards, pads, controllers) and outputs (sound modules, synths) with their names and makers.
2. Live MIDI input is received. A live view shows an on-screen keyboard that lights the notes you play, running counters for messages, notes, and control changes, and a scrolling log that decodes every message: Note On/Off with note name and velocity, Control Change, Pitch Bend, Program Change, and aftertouch. If your setup has a MIDI output, you can send a test note out to it.

A summary verdict at the top names the most likely cause and a recommended next step. A pass needs Web MIDI supported, a device detected, and at least one live message received.

Browser support and SysEx

Web MIDI is not evenly supported, and this tool is honest about that instead of showing a false failure:

• Chrome and Edge (desktop): full support. This is the recommended way to test a device.
• Firefox: supports Web MIDI, but it may need to be enabled and it prompts for permission; on some builds it is unavailable.
• Safari and most iOS browsers: limited or no Web MIDI. Where the API is missing entirely, the test reports not supported - a browser limitation, never a fault with your device.

When should I run this?

• A new or secondhand MIDI keyboard or controller. Confirm every key, pad, knob, and wheel actually reaches the computer before you rely on it.
• A DAW does not see your controller. If the browser sees it here but your DAW does not, the issue is the DAW's MIDI setup, not the hardware or the cable.
• Dead keys or a stuck knob. Watch the log and the on-screen keyboard: a key that never lights or a knob that sends nothing is isolated to that control.
• After a USB or Bluetooth MIDI change. Verify the device still enumerates and sends after re-cabling or re-pairing.
• Checking velocity and pitch/mod wheels. The log shows note velocity and 14-bit pitch-bend values so you can confirm the full range responds.

Reading the results

In the input step the on-screen keyboard lights each note while it is held (Note On lights it, Note Off clears it). The counters tally total messages, distinct notes played, control and pitch-bend messages, and everything else. The live log lists the most recent messages newest-first, each decoded to a readable line.

Each step row carries a status badge: Pending (gray), Running (yellow), Pass (green), Partial (yellow), or Fail (red). A partial is an honest in-between: Web MIDI works but you had no device connected, or a device was listed but sent nothing. That is not a hardware fault, just an incomplete run or a missing device. A browser with no Web MIDI at all reads as a partial not supported, never a fail.

The verdict is a pass only when Web MIDI is supported, access was granted, a device was seen, and at least one live message came through. It is a fail only when access was actively blocked or you cancelled - never merely because your browser lacks the feature.

Copy Diagnostic Report copies a plain-text report: the supported/granted state, every input and output device with its maker, how many messages and distinct notes arrived, the counts by type, and the diagnosis from each step. Paste it into a ticket or a return request.

What the messages mean

The channel (1-16) appears on each line. Most single controllers send on channel 1, but a keyboard split or a multi-part controller may use several.

Common failures and fixes

The tool produces a named diagnosis for each path. In step order:

webmidi-unsupported: the browser has no Web MIDI

The browser does not expose navigator.requestMIDIAccess, so it cannot talk to MIDI at all. This is a partial not supported, not a fault.

1. Open this page in Google Chrome or Microsoft Edge on desktop - both fully support Web MIDI.
2. On Firefox, update to the latest version and allow MIDI when prompted; some builds still gate it behind a setting.
3. Safari and most iOS browsers have limited or no Web MIDI. Switch to Chrome or Edge to test the device.
4. If the page is embedded in another app or an iframe, open it as its own tab - a parent frame can switch off MIDI with a Permissions-Policy.

permission-denied: MIDI access was blocked

The browser supports Web MIDI but the access request was refused.

1. Rerun and choose Allow when the browser asks for MIDI device access.
2. Open the site permissions (the icon left of the address bar), set MIDI to Allow, reload, and rerun.
3. On a managed or work machine, a policy or an extension can block MIDI. Try a personal profile or check with IT.
4. Serve the page over HTTPS (or localhost). Web MIDI is refused on insecure origins.

no-device: Web MIDI works, but no device was connected (partial)

Access was granted but no MIDI input reached the browser during the test.

1. Connect the device by USB, or pair it over Bluetooth MIDI, then rerun. A connected, powered-on device appears automatically - even mid-test.
2. Try another USB cable and port. Charge-only cables carry no data; plug directly into the machine, not an unpowered hub.
3. Bluetooth MIDI must be paired at the OS level first (macOS Audio MIDI Setup). Pairing mode alone is not enough.
4. Confirm the OS sees the device (macOS Audio MIDI Setup, or the vendor tool on Windows). If the OS sees nothing, the fault is the driver, cable, or hardware.

no-input: device detected, but nothing was played (partial)

A device was listed but sent no messages during the input step.

1. Rerun and actually play it - press keys or pads, turn a knob, push a wheel.
2. Close any DAW, synth, or vendor editor that has the device open exclusively, so the browser can receive the MIDI.
3. Check the device is not in a program-edit or local-only mode; some controllers need a bank or mode set to send standard MIDI.
4. Confirm live input in a MIDI monitor. If nothing arrives there either, the problem is upstream of the browser.

For IT and support

MIDI behavior sits on three layers: hardware (the device and its link), OS (class-compliant driver or a vendor one, plus Bluetooth pairing), and per-app (the browser, a DAW, an exclusive-mode grab). This test sees the browser's view, and the failure pattern points at the layer to fix.

Inputs vs. outputs. An input is a device that sends MIDI to the computer (a keyboard, pad, or knob box). An output is a device that receives it (a sound module or synth). Many controllers are input-only, which is normal; the test-note button only appears when an output exists.

Exclusive access. On Windows especially, a DAW or vendor app can hold a MIDI device open so nothing else - including the browser - receives its input. If the browser sees the device but no notes, look for another app holding it.

Class-compliant vs. vendor driver. Most modern USB MIDI gear is class-compliant and needs no driver. If the OS does not enumerate the device at all, a missing vendor driver, a charge-only cable, or an unpowered hub is the usual cause.

SysEx is never requested. This tool passes sysex: false, so it cannot read or write device configuration or firmware. That keeps the permission prompt to the lighter, non-SysEx grant and means the tool cannot alter a device's settings.

Behind the scenes

The Web MIDI API is small. navigator.requestMIDIAccess() returns a promise that resolves to a MIDIAccess with inputs and outputs maps of ports. Each input port fires an onmidimessage event whose data is a Uint8Array: a status byte plus one or two data bytes.

The tool reads the top nibble of the status byte to classify each message - 0x90 Note On, 0x80 Note Off, 0xB0 Control Change, 0xE0 Pitch Bend, 0xC0 Program Change, 0xD0/0xA0 aftertouch - and the low nibble for the channel. Note numbers map to names with Middle C (note 60) as C4. Pitch bend is reassembled from its two 7-bit bytes into a 14-bit value centered at 8192.

A device connected or removed mid-test fires MIDIAccess.onstatechange; the tool re-scans the port list, re-binds the input handlers, and redraws the device list, so hot-plugging just works. When the test finishes or is reset, every input's onmidimessage handler is set to null, the onstatechange listener is removed, and any in-flight test note is sent a Note Off - nothing keeps listening in the background.

Nothing leaves the browser tab: no note, no controller value, no device name, no telemetry, and no SysEx is ever requested. Open DevTools, Network tab, and confirm there are no outbound requests while the test runs.

Related

• MIDI Test - the diagnostic itself
• Controller Test Guide - test a game controller or gamepad
• Keyboard Test Guide - test a computer keyboard's keys and rollover
• USB Test Guide - inspect the port and cable feeding a USB MIDI device
• DeskTest.net home
• About DeskTest.net