Hardware
ViewerUSB Device Viewer
Inspect USB devices in your browser via WebUSB: view vendor & product IDs, manufacturer, USB version, configurations, interfaces and endpoint details.
Have feedback? Report bugs, suggest features, or share your thoughts — we read them allAbout USB Device Viewer
View detailed information about connected USB devices using the WebUSB API. Explore device descriptors including vendor/product IDs, configurations, interfaces, and endpoints. Perfect for USB development, hardware debugging, and understanding USB device structure.
How to use:
- Click 'Select USB device' to open the device picker.
- Choose a USB device from the list of connected devices.
- View detailed device information including IDs and descriptors.
- Explore device configurations, interfaces, and endpoints.
- Check interface classes and endpoint types for your device.
- Use 'Disconnect' to release the device when finished.
Browser Compatibility
- Chrome/Edge (Desktop): Full support
- Opera: Supported
- Firefox/Safari: Not supported
- HTTPS required for security
- User must manually select devices
Technical References
- MDN WebUSB API: https://developer.mozilla.org/en-US/docs/Web/API/USB
- WebUSB Specification: https://wicg.github.io/webusb/
- Chrome Platform Status: https://chromestatus.com/feature/5651917954875392
Frequently Asked Questions
The tool uses the WebUSB API to enumerate connected USB devices that the user explicitly authorizes for browser access. It displays the vendor ID (VID) and product ID (PID) as 16-bit hexadecimal numbers, the manufacturer and product strings stored in the device descriptor, the USB serial number when present, and the full configuration tree — interfaces, alternate settings, endpoints with their direction (IN or OUT), transfer types (control, bulk, interrupt, isochronous), and max packet sizes. It does not show kernel-level information available to system tools like lsusb -v on Linux because the browser sandbox restricts access for security reasons. WebUSB is intended for hobby and prototype work, not for replacing native drivers.
Most users never need to look under the hood, but developers, makers, IT support staff, and curious users benefit in several scenarios. When a device fails to enumerate properly, comparing the descriptor on two computers can isolate whether the device itself is faulty or the host stack misbehaves. Custom hardware projects (Arduino, Raspberry Pi Pico, ESP32 with TinyUSB) need verification that their device descriptors match what they configured in firmware. Counterfeit detection benefits too: a legitimate USB-IF assigned VID like 0x05AC (Apple) on a no-name cable is a red flag. Privacy-conscious users may also inspect what serial numbers and unique identifiers their cables and dongles expose to every computer they plug into.
A well-behaved device exposes a real registered VID (assigned by the USB-IF, costs $6,000 for new vendors), descriptive manufacturer and product strings in UTF-16LE, the correct bcdUSB version (e.g. 0x0200 for USB 2.0, 0x0300 for USB 3.0), and either no serial number or a stable globally-unique one. Red flags include the VID 0x1234 (often used by dev boards without registration), empty string descriptors (just the VID/PID with no human-readable name), inconsistent bMaxPacketSize0 (should be 8, 16, 32, or 64 for full-speed, 64 for high-speed), or a device that reconfigures itself between enumerations (descriptor changes when you unplug and replug). The bcdDevice field can also reveal firmware version when manufacturers update it across revisions.
A USB device speaks through one or more interfaces, each representing a logical function — a printer might expose one interface for printing and another for the scanner. Each interface contains endpoints, which are unidirectional pipes for data: an OUT endpoint receives from the host, an IN endpoint sends to the host. The four transfer types serve different traffic patterns. Control endpoints (always 0) handle setup, descriptors, and standard requests. Bulk endpoints carry large, latency-tolerant data like file transfers. Interrupt endpoints poll small payloads at fixed intervals — used by keyboards, mice, and HID devices. Isochronous endpoints reserve bandwidth without error retry — used by audio and video where dropping a frame is preferable to delaying it. Max packet size on each endpoint dictates the largest single USB transaction.
WebUSB intentionally restricts access to protect users. Devices that already have a class driver loaded by the operating system — keyboards, mice, mass storage, printers, audio devices, smart cards — are blocked by browser policy from WebUSB access, so a malicious website cannot steal your keystrokes or read your USB drive. Only devices that explicitly advertise WebUSB support (via a Microsoft OS 2.0 descriptor with the WebUSB platform capability) or that have no system driver claiming them appear in the chooser. Each authorization is per-origin and per-device: granting access to one website does not grant it to others, and you can revoke permission in the browser's site settings. This is fundamentally different from native lsusb, which sees everything.
Cables themselves are passive but increasingly contain an e-marker chip — a small IC that reports cable capabilities (max current, USB 3.x data lanes, Thunderbolt support, video alternate modes) to the host through the Configuration Channel (CC) pins. WebUSB cannot directly query e-markers, but you can infer cable capability by what device descriptors appear: if you plug a USB 3.x SSD through the cable and it enumerates only as USB 2.0, the cable lacks the SuperSpeed pairs. If a Thunderbolt drive only shows up as USB 3.x, the cable is not Thunderbolt-certified. The most reliable test remains: connect a known-good full-featured device and check that its descriptor reports the expected bcdUSB version.
USB versions in the descriptor (bcdUSB) and marketing names diverge confusingly. USB 1.1 (bcdUSB 0x0110) is 1.5/12 Mbps. USB 2.0 (0x0200) reaches 480 Mbps. USB 3.0 originally (0x0300) is 5 Gbps and was rebranded USB 3.1 Gen 1, then USB 3.2 Gen 1, then USB 5Gbps. USB 3.1 Gen 2 / 3.2 Gen 2 / USB 10Gbps doubles to 10 Gbps. USB 3.2 Gen 2x2 / USB 20Gbps uses dual-lane USB-C for 20 Gbps. USB4 (built on Thunderbolt 3 protocol) goes 20 or 40 Gbps. The descriptor reports the device's native protocol level, but the negotiated speed depends on the host, cable, and chain of hubs. A USB 3.x device on a USB 2.0 hub will report USB 3.x in its descriptor but operate at 480 Mbps.
WebUSB permission grants the origin direct access to vendor-specific endpoints of the authorized device. Once granted, the site can send and receive raw USB transfers to that device for as long as the device is plugged in and the page is loaded. This is appropriate for a single-purpose hardware programming app (e.g. firmware updater for a specific board) but inappropriate for general-purpose sites. Best practices: revoke permission in browser site settings when you stop using the tool, never authorize access to security-sensitive devices like hardware wallets unless the vendor explicitly supports it, prefer authorizing per-session over per-permanent, and verify the site is the legitimate manufacturer URL before clicking allow. WebUSB cannot trigger physical damage on most devices but can corrupt firmware on flashable boards if abused.
CONNECTIVITY5
DEVELOPER TOOLS99
WUTOOLS