JavaScript Navigator hid Property

Beginner
⏱️ 10 min read
📚 Updated: Jul 2026
🎯 5 Examples
🚀 5 Try-it labs
Experimental
Secure context

What You’ll Learn

navigator.hid is the entry point for the WebHID API. Learn the HID object, requestDevice / getDevices, connect events, secure context rules, five examples, and try-it labs.

01

Kind

Read-only property

02

Returns

HID object

03

Status

Experimental

04

Context

Secure (HTTPS)

05

Pick device

requestDevice()

06

Reuse

getDevices()

Introduction

HID means Human Interface Device — keyboards, gamepads, special USB gadgets, and many custom controllers speak the HID protocol. WebHID lets a web page talk to those devices (with the user’s permission).

navigator.hid is read-only. When WebHID is available, it returns an HID object you use to request access, list previously allowed devices, and listen for connect / disconnect events.

💡
Permission first

You cannot silently open every USB gadget on the user’s desk. requestDevice() shows a picker and needs a user gesture (button click). Always explain why you need the device.

Understanding the hid Property

Think of navigator.hid as the WebHID “front desk.” The real work happens on the HID object it returns.

  • HID object — entry point with methods and events.
  • requestDevice() — user picks a device and grants access.
  • getDevices() — list devices already granted earlier.
  • connect / disconnect — events when devices appear or leave.
  • Permissions Policy — if blocked, navigator.hid may be missing entirely.

📝 Syntax

General form of the property:

JavaScript
navigator.hid

Value

  • An HID object when WebHID is available in this context.
  • Missing / unavailable when unsupported, insecure, or blocked by policy.

Common patterns

JavaScript
// Feature-detect:
if ("hid" in navigator && navigator.hid) {
  // WebHID entry point is available
}

// Request a device (must run from a click handler):
async function pickDevice() {
  const devices = await navigator.hid.requestDevice({
    filters: [] // empty = show more devices; prefer real vendor/product filters
  });
  console.log(devices);
}

// List previously granted devices:
const known = await navigator.hid.getDevices();

⚡ Quick Reference

GoalCode
Get WebHID entrynavigator.hid
Detect API"hid" in navigator && navigator.hid
Pick a deviceawait navigator.hid.requestDevice({ filters })
List granted devicesawait navigator.hid.getDevices()
Listen for plug-innavigator.hid.addEventListener("connect", …)
Secure page?window.isSecureContext
Status (MDN)Experimental / not Baseline

🔍 At a Glance

Four facts to remember about navigator.hid.

Returns
HID

WebHID entry

Status
experimental

Not Baseline

HTTPS
required

Secure context

Permission
user gesture

requestDevice

📋 WebHID vs WebUSB (concept)

WebHID (navigator.hid)WebUSB (typical)
FocusHID-class devices (reports / collections)Broader USB device access
Entrynavigator.hidnavigator.usb
PermissionrequestDevice() pickerSimilar user-granted picker
Best forGamepads, specialty HID gadgetsCustom USB protocols
StatusExperimental / limitedAlso limited — check MDN

Examples Gallery

Examples follow MDN WebHID / navigator.hid patterns. Prefer Try It Yourself on HTTPS in a Chromium browser with a real HID device. requestDevice needs a button click.

📚 Getting Started

Detect WebHID and confirm a secure context.

Example 1 — Feature Detection

Check whether the WebHID entry point exists on navigator.

JavaScript
const supported = Boolean(navigator.hid);
console.log(supported ? "WebHID available" : "WebHID missing");
Try It Yourself

How It Works

If missing, show a message and keep a non-HID path (manual setup, native app, etc.).

Example 2 — Secure Context Check

WebHID requires HTTPS / localhost — check both flags together.

JavaScript
console.log("secure: " + window.isSecureContext);
console.log("hid: " + Boolean(navigator.hid));

if (!window.isSecureContext) {
  console.log("Serve over HTTPS to use WebHID");
} else if (!navigator.hid) {
  console.log("Secure, but WebHID not exposed");
} else {
  console.log("Ready to call getDevices / requestDevice");
}
Try It Yourself

How It Works

Policy blocks can also hide navigator.hid even on HTTPS — treat “missing” as unsupported for this page.

📈 Practical Patterns

List granted devices, request a new one, and listen for plug events.

Example 3 — List Granted Devices

getDevices() returns HID devices the user already allowed before.

JavaScript
async function listGranted() {
  if (!navigator.hid) {
    return "WebHID not supported.";
  }
  const devices = await navigator.hid.getDevices();
  return "granted devices: " + devices.length;
}

listGranted().then(console.log);
Try It Yourself

How It Works

On return visits, reconnect to known devices without showing the picker again (until permission is revoked).

Example 4 — Request a Device (Button Click)

Open the picker from a user gesture. Prefer real vendor/product filters in production.

JavaScript
async function pickHidDevice() {
  if (!navigator.hid) {
    throw Error("WebHID not supported.");
  }
  // Demo: empty filters. Real apps pass vendorId / productId / usagePage.
  const devices = await navigator.hid.requestDevice({ filters: [] });
  if (!devices.length) {
    return "No device selected.";
  }
  const d = devices[0];
  return "Selected: " + (d.productName || "HID device");
}

// Call pickHidDevice() from a button onclick — not on page load.
Try It Yourself

How It Works

Calling requestDevice() without a user gesture usually fails. Wire it to a button in the try-it lab.

Example 5 — Connect / Disconnect Listeners

React when a granted HID device is plugged in or removed.

JavaScript
function watchHid() {
  if (!navigator.hid) {
    return { ok: false, message: "WebHID not supported." };
  }
  navigator.hid.addEventListener("connect", (e) => {
    console.log("HID connected:", e.device.productName);
  });
  navigator.hid.addEventListener("disconnect", (e) => {
    console.log("HID disconnected:", e.device.productName);
  });
  return { ok: true, message: "Listening for connect / disconnect" };
}

console.log(JSON.stringify(watchHid()));
Try It Yourself

How It Works

After you set listeners, plug/unplug a previously allowed device to see the console messages in a supporting browser.

🚀 Common Use Cases

  • Specialty controllers — custom gamepads, MIDI-adjacent HID pads, industrial buttons.
  • Device dashboards — configure gadgets that speak HID reports in the browser.
  • Accessibility hardware — niche input devices with user consent.
  • Education / demos — show HID report data for learning electronics.
  • Progressive enhancement — WebHID when available; otherwise guide users to another path.

🧠 How navigator.hid Works

1

Detect the entry point

navigator.hid must exist in a secure context.

Detect
2

User grants a device

requestDevice() from a button click shows the picker.

Permission
3

Reuse with getDevices()

Later visits can reopen previously allowed devices.

Reuse
4

Open, read/write, listen

Use HIDDevice APIs and connect/disconnect events for a full session.

📝 Notes

  • Experimental and not Baseline — support is limited (often Chromium-first).
  • Not Deprecated or Non-standard on MDN.
  • Secure context required (HTTPS / localhost).
  • Permissions Policy can remove navigator.hid entirely.
  • Related: ink, hardwareConcurrency, JavaScript hub.

Limited Browser Support

navigator.hid (WebHID) is Experimental and not Baseline. Availability is limited — historically strongest in Chromium. Always feature-detect, require HTTPS, and keep a fallback.

Experimental · Not Baseline

Navigator.hid

Entry point for WebHID. Detect the HID object, request devices from a user gesture, and listen for connect/disconnect.

Limited Not Baseline
Google Chrome WebHID supported in recent desktop Chrome (secure context)
Supported*
Microsoft Edge Chromium Edge — follows Chrome WebHID support
Supported*
Opera Chromium-based — WebHID where Chromium enables it
Supported*
Mozilla Firefox Not available for typical web content — check current MDN
Unavailable
Apple Safari Not available for typical web content — check current MDN
Unavailable
hid Limited

Bottom line: Detect WebHID over HTTPS, call requestDevice from a click, and never require HID for core site features.

Conclusion

navigator.hid is the WebHID entry point. Feature-detect it in a secure context, call requestDevice() from a button click, reuse access with getDevices(), and listen for connect / disconnect when you need live plug events.

Continue with ink, hardwareConcurrency, or the JavaScript hub.

💡 Best Practices

✅ Do

  • Feature-detect navigator.hid first
  • Serve over HTTPS / localhost
  • Call requestDevice() from a user gesture
  • Use vendor/product filters when you know the device
  • Provide a clear non-HID fallback

❌ Don’t

  • Assume Safari/Firefox expose WebHID
  • Call the picker on page load
  • Require HID for essential site features
  • Ignore Permissions Policy / iframe restrictions
  • Skip explaining why you need the device

Key Takeaways

Knowledge Unlocked

Five things to remember about hid

Experimental WebHID entry — detect, ask, then talk to the device.

5
Core concepts
🔒 02

HTTPS

Secure context

Required
🔑 03

Pick

requestDevice

Gesture
📋 04

Reuse

getDevices

Granted
🔬 05

Status

Experimental

Detect

❓ Frequently Asked Questions

It is a read-only Navigator property that returns an HID object — the entry point for the WebHID API so your page can access HID device connections and listen for connect/disconnect events.
Yes. MDN marks it Experimental and not Baseline. Support is limited (historically strongest in Chromium). Always feature-detect and provide a non-HID fallback.
Yes. It is available only in secure contexts (HTTPS or localhost) in supporting browsers.
navigator.hid.requestDevice(options) opens the browser’s device picker so the user can grant access to a selected HID device. Call it from a user gesture such as a button click. It resolves to an array of HIDDevice objects.
navigator.hid.getDevices() returns devices the user already granted access to earlier via requestDevice(). It does not show a new picker by itself.
Unsupported browser, insecure context, or a Permissions Policy that blocks WebHID — MDN notes the property will not be available when policy blocks usage.
Did you know?

MDN warns that when a Permissions Policy blocks WebHID, Navigator.hid is simply not available — your feature-detect should treat that the same as “unsupported.”

Explore ink Next

Learn the Ink API for smoother stylus drawing trails.

ink →

About the author

Mari Selvan M P
Mari Selvan M P 🔗

Developer, cloud engineer, and technical writer

  • Experience 12 years building web and cloud systems
  • Focus Full Stack Development, AWS, and Developer Education

I write practical tutorials so students and working developers can learn by doing—from databases and APIs to deployment on AWS.

8 people found this page helpful