WebHID: Browser Support, API, Limitations

What is WebHID?

WebHID is a JavaScript API that gives a web page raw access to Human Interface Device reports over USB and Bluetooth, exposed through the navigator.hid object. The Web Platform Incubator Community Group at the W3C edits the spec, and Matt Reynolds at Google is the editor. WebHID first shipped in Chrome 89 in March 2021 to let web apps work with gamepads, joysticks, headsets, presenters, and other devices that lack a custom browser API.

Which browsers does WebHID support?

Chromium-based desktop browsers ship WebHID by default, while Firefox, Safari, and every mobile browser leave it out, so global browser support sits at about 27% as of April 2026.

What are the key features of WebHID?

WebHID gives a web page low-level access to HID input, output, and feature reports without a native driver, while keeping the user in control of every device handshake. The headline features focus on permissions, raw report I/O, and event-based device updates.

• navigator.hid.requestDevice: Pops a browser-supplied device chooser on a click. The user picks a device from a filter list of vendor and product IDs, and the page only sees the device the user chose.
• navigator.hid.getDevices: Returns the list of devices the user has already approved for the origin. The page never gets a free pass to enumerate hardware.
• HIDDevice.open and HIDDevice.close: Open and close the device handle. Only one tab can hold the handle at a time, so the API surfaces a clear lifecycle.
• sendReport, sendFeatureReport, receiveFeatureReport: Send output and feature reports to the device, and read feature reports back. Each call takes a report ID and a Uint8Array buffer.
• inputreport event: Fires every time the device pushes an input report. The event carries data, reportId, and the originating HIDDevice.
• connect and disconnect events: Fire on the navigator.hid object when an approved device is plugged in or unplugged. Pages can react to USB cable changes without polling.
• HIDDevice.forget: Revokes the page's permission for that device. The next requestDevice call must show the chooser again.
• Built-in blocklist: Generic keyboards, mice, pointer devices, and FIDO HID authenticators are blocked by Chrome at the browser layer. The page cannot bypass this list.

How do you connect to an HID device with WebHID?

You connect to an HID device by feature-detecting navigator.hid, calling requestDevice from a user gesture, opening the returned device, and listening for inputreport events. Every step has to run on a click or keypress because requestDevice requires user activation.

Use the filters argument to narrow the chooser to your hardware. A filter can match vendorId, productId, usagePage, and usage. The browser shows the user every device that matches at least one filter.

Paste this snippet into the DevTools console of Chrome, Edge, or Opera. Click anywhere on the page once and the device chooser opens.

// Paste this into the DevTools console to confirm WebHID support and request a device.
if ("hid" in navigator) {
  console.log("WebHID is available.");

  document.body.addEventListener("click", async () => {
    const filters = [{ vendorId: 0x057e }]; // example: any Nintendo HID device
    const devices = await navigator.hid.requestDevice({ filters });

    if (devices.length === 0) {
      console.log("No device selected.");
      return;
    }

    const device = devices[0];
    await device.open();
    console.log("Opened device:", device.productName);

    device.addEventListener("inputreport", (event) => {
      const { data, reportId } = event;
      console.log("Report", reportId, new Uint8Array(data.buffer));
    });
  }, { once: true });
} else {
  console.log("WebHID is not supported in this browser.");
}

If the console prints "WebHID is not supported in this browser", you are running Firefox, Safari, or a mobile Chromium browser. Fall back to a native helper app or a Trusted Web Activity for those visitors.

What are the known issues with WebHID?

WebHID has the smallest browser footprint of any modern device API. The painful edge cases tend to land on Firefox refusal, mobile gaps, and the user-gesture rule.

• Firefox calls WebHID harmful: Mozilla flags WebHID as harmful in its standards position. Sites that need HID on Firefox must ship a native helper or guide users to Chrome or Edge.
• No Safari, no iOS, no iPadOS: Safari on macOS, iPadOS, and iOS lack WebHID. iPad and iPhone visitors need a native app or a sidecar tool, since there is no flag to enable.
• No Chrome for Android or Samsung Internet: Mobile Chromium builds disable the WebHID feature. Android visitors get a silent undefined when the page reads navigator.hid.
• requestDevice must run on a user gesture: Chrome throws DOMException "Must be handling a user gesture" if you call requestDevice from a setTimeout, fetch callback, or page-load handler. Always wire it to a click or keypress.
• Generic keyboards and mice are blocked: Chrome refuses to expose any device whose top-level usage matches a keyboard, mouse, pointer, or system multi-axis controller. The blocklist also covers FIDO HID authenticators.
• Service workers cannot call requestDevice: Chrome extensions must call requestDevice from an extension page and pass the device handle to the service worker through messaging. The Chrome team documents this restriction in the WebHID extension guide.
• Bluetooth HID needs OS pairing first: The browser only sees Bluetooth HID devices the operating system has already paired and connected. Pair your headset or controller in Windows, macOS, or ChromeOS settings before you call requestDevice.
• One tab owns the device: Once a tab opens the device, no other tab can open it until the first tab calls close or is destroyed. Plan your UX so users do not race two pages onto the same gamepad.

In my experience, the trickiest failure is the user-gesture rule paired with React. A useEffect that calls requestDevice on mount throws every time, even after a real click somewhere else, because the browser has already lost the activation token by the time the effect runs. Wire requestDevice to an onClick handler on a real button and the problem disappears.

Citations

All WebHID version numbers and platform notes in this guide come from these primary sources:

• MDN Web Docs - WebHID API: developer.mozilla.org/en-US/docs/Web/API/WebHID_API
• MDN Web Docs - HID interface: developer.mozilla.org/en-US/docs/Web/API/HID
• WICG - WebHID API editor's draft: wicg.github.io/webhid
• WICG - WebHID Explainer: github.com/WICG/webhid/blob/main/EXPLAINER.md
• Chrome for Developers - Connecting to uncommon HID devices: developer.chrome.com/docs/capabilities/hid
• Chrome for Developers - Use WebHID in Chrome Extensions: developer.chrome.com/docs/extensions/how-to/web-platform/webhid
• Chrome Platform Status - WebHID feature: chromestatus.com/feature/5172464636133376
• Chromium - How to file WebHID bugs: chromium.org/developers/how-tos/file-web-hid-bugs
• Mozilla Specification Positions - WebHID: mozilla.github.io/standards-positions
• Mozilla Connect - WebHID API Support, please: connect.mozilla.org/t5/ideas/webhid-api-support-please/idi-p/4780
• WebKit - Standards Positions: webkit.org/standards-positions
• Awesome WebHID resources: github.com/robatwilliams/awesome-webhid