What bytes should I paste into the USB PD message decoder?

Paste the two message-header bytes followed by the declared 32-bit data objects, in wire byte order. Do not include preamble, SOP symbols, or CRC unless you enable the CRC option.

Can this tool decode a raw CC waveform?

No. It starts after BMC, 4b5b, SOP, and CRC handling. Use a USB PD protocol analyzer or controller trace to obtain message bytes first.

Does a clean result prove USB-IF compliance?

No. The tool checks declared bit fields and a basic power-contract sequence. It does not test electrical levels, timing, state-machine completeness, CRC correctness, protection, cable construction, or USB-IF compliance.

USB Power Delivery 3.2 inspector

USB PD Message Decoder: PDO, RDO, AVS and Cable VDO

Turn analyzer bytes into named USB PD messages, power capabilities, requests, and cable identity fields. The sequence view also checks the core path from advertised capabilities to PS_RDY.

Tool Published Jul 21, 2026 Reviewed against USB-PD R3.2 V1.2

Contract checker Hardware design guide

Message input

Header + 0 to 7 data objects

Byte order

Wire bytes, little-endian fields

Object support

Fixed, battery, variable, PPS, AVS

Privacy

Decoded locally; input is not uploaded

Contract timeline

One message per line

Optional prefixes: TX:, RX:, SOP:. GoodCRC lines are shown but ignored by the contract state check.

PD message bytes

Input includes final 4-byte CRC

Address

CRC bytes can be removed from the input length check, but this tool does not calculate or validate the CRC.

Decode result

Decoding...

Bench workflow

Where these bytes come from

01Capture CC traffic with a USB PD analyzer, PD-capable oscilloscope decoder, or the trace output of your port controller.
02Export each decoded message as header and payload bytes. Keep message boundaries; one line in the sequence view equals one PD message.
03Use TX: and RX: labels when available. They are preserved for reading but the role bits in the PD header remain authoritative.
04Return to the original analyzer when the issue involves CC voltage, BMC symbols, timing, retries, CRC, resets, or electrical compliance.

Byte-order check

Do not reverse the whole packet

Wire bytes: A1 61 2C 91 01 08 ...
Decoded 16-bit header: 0x61A1 - Source_Capabilities, 6 objects
First decoded 32-bit PDO: 0x0801912C - fixed 5 V / 3 A

Object-only and cable-identity modes instead expect the already assembled 32-bit words shown by most controller logs.

Interpretation limits

A complete four-message path is useful evidence, not proof of a correct implementation. EPR entry and exit, swaps, resets, extended-message chunking, timing, source power rules, cable authenticity, and electrical behavior need the full trace and the applicable USB-IF test procedures. An e-marker reports claims stored in the cable; software cannot verify the conductors or insulation inside it.

USB PD decoding FAQ

Why does the header object count matter?

The three-bit field declares zero to seven 32-bit objects. A byte count mismatch usually means the capture still includes SOP/CRC bytes, a message boundary was lost, or the byte order was copied incorrectly.

Can a Request RDO be decoded without Source_Capabilities?

Its object position and raw fields can be shown, but their current, power, or programmable-voltage meaning depends on the selected PDO. The sequence view retains the preceding Source_Capabilities so it can apply the correct layout and limits.

Does EPR capable mean a cable is genuinely safe for 240 W?

No. It means the identity data claims EPR capability and the associated voltage/current fields can be checked for internal consistency. Only certified testing and physical construction can establish actual cable performance.

Specification and implementation references

Field layouts were reviewed against the USB-IF USB Power Delivery Specification Revision 3.2 Version 1.2, published May 20, 2026. The message, PDO, RDO, and VDM definitions were cross-checked with the Linux kernel pd.h and pd_vdo.h headers. Current cable VDO interpretation was also compared with the open-source WhatCable decoder and its public test corpus. USB-IF specifications remain authoritative.