USB VID/PID lookup for bench tools: 53 chips, programmers and probes, and the driver each one needs

Every USB device announces itself with two 16-bit numbers, a Vendor ID and a Product ID, and the operating system picks the driver from that pair before it reads anything else. If you can read the pair, you can name the chip on a no-name board, tell a programmer from its clone, and know which driver page to open. Below: where the pair is shown on each OS, a lookup table of 53 bench devices (more than 90 VID:PID pairs) built from the kernel drivers, the tools’ own source code and the usb.ids database, and six cases where the number says less than people think.

Where to read the pair

Windows: Device Manager, right-click the device, Properties, Details tab, property Hardware Ids. The first line reads, for example, USB\VID_067B&PID_2303&REV_0300: vendor, product, and the device’s own revision number. This works even when the device sits under “Other devices” with a yellow mark, which is exactly when you need it. Linux: lsusb prints ID 1a86:7523 plus a name, if the ID is in the usb.ids file. macOS: system_profiler SPUSBDataType lists “Vendor ID” and “Product ID” per device.

The lookup table

IDs are written the way Windows shows them (upper-case hex). Where one device has several IDs, they are listed in the order of the names. “Guide” links to the TechBenchLab post that hosts the driver or tool. Sources are per row group and listed at the end.

USB-to-serial bridges

Native-USB microcontrollers, bootloaders and phone download modes

Programmers and debug probes

Logic analyzers and scopes

Six things the number does not tell you

1. Three programmers, one PID. The TL866II Plus, the T48 and the T56 all enumerate as A466:0A53; the minipro project’s udev file carries one rule for the three. The model only becomes known after the software talks to the device, which is why a T56 with the wrong Xgpro version still “installs” and then fails.
2. Some devices change ID after you open them. A Hantek 6022BE plugs in as 04B4:6022; the moment sigrok uploads its firmware the scope re-enumerates as 1D50:608E. The same happens to a Saleae clone, 0925:3881 to 1D50:608C. Device Manager shows two different devices over time, and Zadig has to be applied to the first one.
3. The PL2303 generation lives in REV, not in the PID. Every HXA, HXD, TA and TB answers 067B:2303. The Linux driver decides the type from bcdUSB and bcdDevice: USB 1.1 with device revision 0300 is HX(A), 0400 is HXD; USB 2.0 with 0300 is TA, 0500 is TB. On Windows that revision is the REV_0300 at the end of the Hardware Id, which is how you know in advance whether the “Phased Out” message is coming.
4. 1A86:7523 is not always a CH340. WCH’s newer CH343C claims the same pair with REV_8234, and the two INF files name it differently; the CH9102 / CH343 guide above has the full INF table.
5. lsusb knows fewer vendors than you expect. The usb.ids release of 26 June 2026 has no entry for vendor 2E8A (Raspberry Pi) or 303A (Espressif), so a Pico or an ESP32-S3 shows up as bare numbers with no name. The device is fine; the database is behind.
6. One probe, two IDs by mode. A WCH-LinkE is 1A86:8010 in RISC-V mode and 1A86:8012 in ARM mode; the switch is done by the WCH tool, not by the cable. A J-Link encodes whether it is in SEGGER-driver or WinUSB mode inside the PID itself.

FAQ

Device Manager shows no VID at all, only “Unknown USB Device (Device Descriptor Request Failed)”. What now? The host never got the descriptor, so no driver was ever a candidate. That is a cable, hub, power or dead-chip problem, not a driver one. Try another cable and a rear port before downloading anything.

The pair is in the table but the yellow mark stays after installing the driver. Check REV and the interface. A composite device (ST-Link/V2-1, ESP32-S3, Black Magic Probe) exposes several interfaces under one PID; the driver you installed may cover only one of them, and Zadig applied to the wrong interface takes a working port away.

Can I trust a VID to prove a chip is genuine? No. The VID:PID is written into the chip or its EEPROM by whoever made the board; clones copy it on purpose, which is the whole story behind the FTDI and Prolific driver lockouts.

Related guides

• CH340 driver for Windows 11 and CP2102 driver: the two pairs behind most of this site’s traffic
• Zadig + USBasp: when the right driver is “no driver” (WinUSB)
• USB microscope not detected: reading the VID/PID of a camera that has no driver at all
• Arduino IDE 2: port not showing: the 141 VID/PID pairs in the official boards.txt files

Sources

• Linux USB project, usb.ids, version 2026.06.26 (names for 1A86, 10C4, 0403, 067B, 0483, 03EB, 04D8, 0925, 21A9, 04B4/04B5, 1366, 15BA, 1AB1, 16C0, 16D0, 05C6, 0E8D, 0D28, 2341, A466)
• Linux kernel, drivers/usb/serial/ch341.c, cp210x.c, ftdi_sio_ids.h, pl2303.h and pl2303.c (pl2303_detect_type())
• OpenOCD, contrib/60-openocd.rules (ST-Link, J-Link, CH347, Espressif 303A:1001/1002); probe-rs, 69-probe-rs.rules
• minipro, udev/60-minipro.rules (TL866A/CS, TL866II+/T48/T56, T76)
• Raspberry Pi, picotool picoboot_connection.h; pico-sdk stdio_usb_descriptors.c; debugprobe usb_descriptors.c
• Espressif, esp-pylib constants.py (ESPRESSIF_VID, USB_JTAG_SERIAL_PID); ESP-IDF DFU guide (303A:0002)
• Arm Mbed, DAPLink usb_config.c (0D28:0204); ch32-rs, wlink src/probe.rs (WCH-Link 8010/8012); Black Magic Debug usb_descriptors.h
• avrdude, avrdude.conf.in (usbasp, usbtiny, avrispmkII, dragon_isp, jtag3isp)
• sigrok, libsigrok fx2lafw/api.c, hantek-6xxx/api.c, dreamsourcelab-dslogic/api.c
• bkerler, mtkclient usb_ids.py and edl usb_ids.py (MediaTek, Qualcomm)
• Microsoft Learn, Standard USB identifiers (the USB\VID_xxxx&PID_xxxx&REV_xxxx format)