Wiki · Concept · Last reviewed June 25, 2026

WebHID API

The WebHID API exposes selected human interface devices to web pages, creating a browser boundary for agents, peripherals, and physical controls.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser security, hardware, agents, permissions

Definition

The WebHID API is a Web Platform Incubator Community Group specification for browser access to devices that support the Human Interface Device protocol. The specification describes HID as both a device category and a bidirectional protocol between a host and a device. It began with USB devices and is now also implemented over other protocols, including Bluetooth.

WebHID is for devices and device features that ordinary high-level web APIs do not cover: alternative keyboards, specialized controllers, unusual gamepads, headset controls, foot pedals, lab panels, assistive switches, classroom hardware, and other peripherals whose useful controls are described by HID reports. It is not the same as keyboard events, the Gamepad API, WebUSB, or Web Serial, although a single physical device may sit near several of those categories.

MDN lists the core interfaces as HID, HIDDevice, HIDInputReportEvent, and HIDConnectionEvent. The governance question is simple: what happens when a web page, and therefore a browser agent, can exchange low-level reports with a local input or output device?

Snapshot

Current Context

At this June 25, 2026 review, WebHID remains an incubator specification rather than a W3C Recommendation. The WICG draft was published as a Draft Community Group Report on September 13, 2024 and says it is not a W3C Standard or on the W3C Standards Track.

MDN marks WebHID and the hid Permissions Policy directive as limited availability and experimental. It also notes that WebHID is available in Web Workers except Shared Web Workers in supporting browsers. Chrome documents the API for uncommon HID devices and exposes user-facing settings for websites that connect to USB, Serial, or HID devices.

Chrome's user help is unusually direct about the stakes: users should grant device access only to trusted sites, and a paired site can access device information and may be able to reprogram the device. For governance, that means WebHID should be treated as hardware access even when it appears inside an ordinary web page.

Mechanism

The API is reached through navigator.hid, with related exposure on worker navigators in supporting contexts. A page asks for access by calling requestDevice() with device filters. The user agent presents a chooser, and the user grants access to selected devices. The WICG method steps require transient user activation, so the request must be connected to an actual user interaction. After permission is granted, getDevices() can list devices already available to the site.

Filters can include vendorId, productId, usagePage, and usage; the draft also defines exclusionFilters so a site can hide known-bad or unsupported devices from the chooser. Filters narrow what appears in the prompt. They do not prove that a selected device is safe, authentic, correctly labeled, or appropriate for a user's physical environment.

HID communication is organized around reports and report descriptors. Chrome's documentation describes input reports as data sent from the device to the application, output reports as data sent from the application to the device, and feature reports as device-specific data that may move either way. That makes WebHID more specific than ordinary keyboard events. It can expose LED control, rumble, configuration state, sensors, buttons, audio controls, foot switches, and other report-level behaviors that high-level browser APIs may hide.

An HIDDevice can be opened and closed, can receive input reports, and can send output or feature reports. The draft also defines forget(), which gives a page a way to release a previously granted permission. A governance review should care about all four states: selected, open, active report exchange, and forgotten or revoked.

Permissions Policy is part of the boundary. MDN says the hid directive controls whether a document may use WebHID, and the default allowlist is self. Cross-origin frames should therefore receive HID access only by deliberate delegation, not as a side effect of being embedded in a page that also hosts a device control panel.

Agent Context

For AI Browsers and Computer Use, WebHID is another place where a model can move from interface text into device state. An agent may configure a keypad, test a controller, read a sensor, operate a headset button surface, or drive an exotic input panel. It may also misread a prompt, accept a device it cannot identify, or generate report data that a human never meant to send.

The risk is not that HID devices are suspicious by default. The risk is that HID devices often sit close to the user's body, workflow, or physical environment. A foot pedal, assistive switch, game controller, scanner, headset, or custom lab controller is not just an abstract peripheral. It is part of how a person acts. Agentic automation around that channel should make authority visible.

Agent systems should therefore treat WebHID prompts as physical-device prompts, not generic browser permission banners. A model should not be allowed to choose devices, approve report-writing, or continue after unexpected connect/disconnect events without a policy layer that understands the device class and the human's intent.

Governance Use

A governance review should treat WebHID as hardware authority. Record the top-level origin, frame origin, Permissions Policy, selected device, vendor and product identifiers when available, usage page, usage, report IDs, report direction, user gesture, permission state, and whether the page sends output or feature reports. If a model is involved, record the prompt, generated report data, tool calls, human confirmation path, and whether any device action was irreversible or persistent.

Organizations should separate device configuration surfaces from untrusted content. A support portal, controller setup page, accessibility-device tool, classroom device portal, or factory diagnostic page should not casually share an origin with advertising scripts, model-generated previews, unreviewed plugins, or third-party widgets. If the same browser profile is used by an agent, the review should also ask whether granted HID permissions survive across tasks.

Enterprise policy should prefer allowlists over broad trust. Approved origins, permitted vendor/product IDs, permitted usage pages, and allowed report directions should be documented before deployment. For high-risk workflows, output and feature reports should require human confirmation or a deterministic allowlist outside the model.

Limits

The WICG specification's security section warns that HID peripherals can expose powerful functions: sensors, stored private information, writable settings, and firmware-update paths. It also notes that access can be abused to damage a device or corrupt data on it. The WebHID blocklist and user prompt reduce risk, but they cannot interpret every device-specific report.

The browser usually cannot know whether a report turns on a harmless light, changes a safety setting, mutes a microphone, changes calibration, writes to persistent memory, or starts a firmware-update path. Device makers and deployers still need firmware signing where appropriate, anti-rollback protections, safe defaults, clear reset paths, command allowlists, physical safety checks, and logs that distinguish device input from web-page output.

Chrome adds practical mitigations by inspecting top-level collection usages and blocking protected usages such as generic keyboard and mouse behavior, and by blocking security-sensitive devices such as FIDO HID devices. Those mitigations are important, but they are not a general proof that every accessible report is safe for arbitrary automation.

Failure Modes

Chooser confusion. A user or agent selects a similarly named device, a composite device, or a device whose physical context is not visible in the browser UI.

Report opacity. A payload is syntactically valid HID data but semantically dangerous for the device, such as a persistent setting, diagnostic mode, calibration change, or firmware action.

Cross-origin delegation error. A first-party page delegates hid access to an embedded widget, support tool, or untrusted frame that should not hold hardware authority.

Permission persistence. A later session reuses previously granted device access after the user, device, task, or physical environment has changed.

Assistive-device harm. An accessibility switch, foot pedal, or custom controller is disrupted in a way that affects the user's work, mobility, communication, or care routine.

Agent overreach. A model treats report-writing as a normal form submission and sends bytes without understanding the physical consequence or needing fresh human confirmation.

Review Record

Source Discipline

Claims about the API shape, chooser flow, filters, reports, blocklist, and Permissions Policy integration should cite the WICG WebHID specification. Claims about browser support, secure-context status, worker exposure, and interface names should cite current browser documentation, because MDN currently marks WebHID as limited availability and experimental.

Claims about Chrome behavior should separate developer documentation, user-facing Chrome Help, Chrome Enterprise policy pages, and implementation source. A permission prompt is evidence of user-mediated access, not evidence that the connected device is safe for arbitrary commands.

Spiralist Reading

Spiralism reads WebHID as a reminder that "interface" is sometimes literal. The hand, switch, controller, sensor, and indicator light become part of the web session. When an agent acts there, the record should preserve the chain from language to report to device behavior. The humane boundary is not no hardware; it is named hardware, narrow permission, reversible action, and a user who still knows what is listening.

Open Questions

Sources

Return to Wiki