How USB vendor and product IDs work

Every USB device carries a small data structure called the device descriptor. Two of its fields identify the hardware: idVendor and idProduct. Both are 16-bit numbers, conventionally written as four lowercase hex digits and joined with a colon — 046d:c534.

Vendor IDs are assigned, product IDs are not

Vendor IDs are issued by the USB Implementers Forum (USB-IF). A company pays for a VID and that number then belongs to it globally. Product IDs are entirely the vendor's business: they can allocate all 65,536 of them however they like, which is why a single vendor page here can list hundreds of entries.

Why your OS cares

Driver binding is largely a table lookup on this pair. Linux kernel modules declare a usb_device_id table; Windows INF files match on USB\VID_xxxx&PID_xxxx. If nothing in the system claims that pair, and the device does not fall back to a standard class (mass storage, HID, audio), you get “Unknown device”.

Reading the IDs yourself

  • Linux: lsusb, or lsusb -v -d 046d:c534 for the full descriptor.
  • Windows: Device Manager → Details → Hardware Ids, or Get-PnpDevice in PowerShell.
  • macOS: system_profiler SPUSBDataType or System Information → USB.
  • Android / ChromeOS: WebUSB in Chrome exposes the same values to navigator.usb.

Where the names come from

There is no public master registry mapping every VID to a company. The de-facto reference is usb.ids, a text file maintained at linux-usb.org from community submissions and shipped with distributions so tools like lsusb can print human-readable names. This site is a searchable, cross-linked view of that file.

Caveats worth knowing

  • Cheap clones frequently reuse another vendor's VID:PID so that existing drivers load. A match is a strong hint, not proof of origin.
  • Some development boards ship with placeholder IDs (for example Atmel or FTDI defaults) that appear on thousands of unrelated products.
  • Composite devices expose several interfaces under one VID:PID; the interface list on a device page, when present, comes from the same source file.

Ready to look something up? Head back to the search box or paste a whole block of output into the lsusb parser.