ByteScope

HID Report Descriptor Inspector

Plug in a HID device and read exactly what it tells the host — the decoded descriptor, a bit-level field map and live input reports.

Reads HID devices locally in your browser — nothing is uploaded.

No device connected

Checking browser support…

Browser Support Matrix

WebHID is currently supported in Chromium-based desktop browsers. Learn more about WebHID support

FeatureChromeEdgeFirefoxSafari
navigator.hid device pickerChromium desktop browsers only.SupportedSupportedNot supportedNot supported
Live input reportsReceives live input reports via WebHID.SupportedSupportedNot supportedNot supported
Connecting a device on AndroidWe have not tested this on Android. Firefox ships no WebHID on any platform, and Safari does not exist on Android.UntestedUntestedNot supportedNot applicable
Paste-a-descriptor decodingPure computation — works in all browsers, no device attached.SupportedSupportedSupportedSupported
Opening a keyboard or mouseWindows blocks top-level keyboard and mouse collections from WebHID entirely; macOS and Linux generally allow them.Partial supportPartial supportNot supportedNot supported

Detected browser capabilities

  • navigator.hid …
  • Secure Context (HTTPS) …

About this tool

This inspector connects to a USB HID device through the WebHID API: click Connect, pick your keyboard, gamepad, barcode scanner or custom firmware board from the browser's device picker, and the page lists its collections and reports, then decodes the report descriptor into the same indented listing the classic desktop tools produce — Usage Page, Usage, Collection, Logical Minimum/Maximum, Report Size, Report Count and the Input/Output/Feature flags, item by item. Everything runs locally in your browser, nothing is uploaded, and this version is strictly read-only: it never sends a byte to the device.

Decode the descriptor, field by field

The report descriptor is the block of bytes every HID device hands the host to declare what data it will send — it's why a keyboard just works without a driver, and it's the first thing you check when a custom device doesn't. Below the raw listing, a table breaks out every input, output and feature report: report ID, size in bytes, and each field's bit offset, bit width, usage name (Generic Desktop / X, Keyboard LeftControl, Button 3), logical range and flags — the exact map you'd otherwise reconstruct by hand from the HID Usage Tables with a notepad and a lot of patience.

Watch the bits change live

Open the device and input reports stream in as they arrive: raw hex bytes on one side, the per-field decoded values on the other. Press a key, move a stick, scan a barcode — and watch exactly which bits change, which is usually all it takes to find an off-by-one bit offset or a field your firmware packs differently than its descriptor claims. WebHID is a Chromium-only API (Chrome, Edge and Opera on desktop, with Chrome on Android reported to work but untested by us; Firefox and Safari don't implement it), and some devices are claimed by the operating system before the browser can open them — the FAQ below covers exactly which ones and why.

Frequently asked questions

Why doesn't my keyboard or mouse show up in the picker?

On Windows, Chromium blocks keyboards and mice outright — a page that could read raw keyboard reports could log keystrokes meant for other apps, so they never appear in the picker. On macOS the browser can usually open them. Separately, WebHID blocks certain protected usage pages (FIDO security keys, for example) on every OS, and a device exclusively claimed by a driver can't be opened by the browser at all.

What is a report descriptor, exactly?

It's a compact byte stream every HID device presents when it enumerates, declaring the structure of every report it will send or accept: which Usage Page and Usage each field belongs to, how many bits it occupies, its logical range, and whether it's an Input, Output or Feature item. The host parses it once and then knows how to interpret every report — which is why HID devices need no custom driver, and why this descriptor is the ground truth when you're debugging one.

Is anything from my device uploaded?

No. WebHID talks directly between your browser and the device — the descriptor, the report tables and every input report you watch stay on your machine. The site's analytics record only that the tool was used, never any device data.

Can it write to the device — send output or feature reports?

No, and that's deliberate. This version never calls sendReport() or sendFeatureReport(): it only reads the descriptor and listens to input reports, so it's safe to point at hardware you're still reverse-engineering. Writing feature reports is planned for a later version.

The decoded fields don't match my firmware code — why?

The tool decodes exactly the bytes your device sent, so a mismatch usually means the descriptor doesn't say what you think it says. The usual suspects: when a device uses report IDs, the first byte on the wire is the ID and every offset shifts by 8 bits; padding items (Report Size × Report Count with no Usage) take up bits your code skips silently; and a field's byte order follows the descriptor's bit layout, not your struct definition. Compare the indented listing against the descriptor you wrote — the disagreement is almost always in there.