Free CAN Frame Decoder
Paste CAN frames and the DBC that describes them to turn raw bytes into signal values with units.
What is a CAN Frame Decoder?
Raw CAN traffic is identifiers and bytes. A DBC file says what those bytes mean. This decoder combines the two and prints every signal’s value, the way a bus analyser would.
It reads frames in the formats Linux SocketCAN tools write, from cansend’s 123#DEADBEEF to candump logs with timestamps, and decodes them with Intel and Motorola signals, signed and float values, value tables and multiplexing. Several frames decode at once, so a short capture reads like a table of values.
Key Features
Every candump Format
cansend and candump -L syntax, candump -l log lines with timestamps, the default candump output, or an ID and spaced bytes.
Physical or Raw
See scaled values with units and value-table labels, or the unscaled integers when checking a decoder.
Multiplexing Handled
Multiplexed signals are decoded only for the multiplexor’s current value, as a real decoder does.
Extended and CAN FD
29-bit identifiers, remote frames and CAN FD payloads up to 64 bytes are read.
Logs Stay Private
Frames and the database are decoded in your browser and never uploaded.
Perfect for everyone
- Automotive and embedded engineers
- CAN bus reverse engineers
- Anyone with a candump log and a DBC
How to Use the CAN Frame Decoder
Paste frames, add the DBC, and read the values.
Capture or Paste Frames
Use candump -l to log traffic, or paste a few frames copied from a terminal.
Add the DBC
Paste the .dbc file or open it. It must describe the identifiers in your frames.
Read the Values
Each frame shows its message name and every signal with units and labels.
Switch to Raw
Raw values shows the integers before scaling, useful when checking your own decoder.
Frames, Decoded
Each row is CAN frames, a line of three dashes, then the DBC lines used to decode them. Every answer is this decoder’s output in the mode on the chip.
“100#803E5A0000000000 --- BO_ 256 EngineData: 8 ECU SG_ EngineSpeed : 0|16@1+ (0.125,0) [0|8031.875] "rpm" ABS SG_ CoolantTemp : 16|8@1+ (1,-40) [-40|215] "degC" ABS VAL_ 256 CoolantTemp 0 "Sensor fault" 255 "Not available" ;”
“(1792919642.120481) can0 100#803E5A0000000000 (1792919642.130481) can0 100#003F5B0000000000 --- BO_ 256 EngineData: 8 ECU SG_ EngineSpeed : 0|16@1+ (0.125,0) [0|8031.875] "rpm" ABS SG_ CoolantTemp : 16|8@1+ (1,-40) [-40|215] "degC" ABS VAL_ 256 CoolantTemp 0 "Sensor fault" 255 "Not available" ;”
“ can0 200 [8] 1A 2C 00 00 00 00 00 00 --- BO_ 512 WheelSpeed: 8 ABS SG_ VehicleSpeed : 7|16@0+ (0.01,0) [0|655.35] "km/h" ECU”
“100#803EFF0000000000 --- BO_ 256 EngineData: 8 ECU SG_ EngineSpeed : 0|16@1+ (0.125,0) [0|8031.875] "rpm" ABS SG_ CoolantTemp : 16|8@1+ (1,-40) [-40|215] "degC" ABS VAL_ 256 CoolantTemp 0 "Sensor fault" 255 "Not available" ;”
“300#0001 300#0102 --- BO_ 768 DoorStatus: 2 BCM SG_ Page M : 0|4@1+ (1,0) [0|15] "" ECU SG_ FrontLeftOpen m0 : 8|1@1+ (1,0) [0|1] "" ECU SG_ RearLeftOpen m1 : 8|1@1+ (1,0) [0|1] "" ECU VAL_ 768 Page 0 "Front doors" 1 "Rear doors" ;”
“18FEF1FE#40E20100FFFFFFFF --- BO_ 2566844926 Odometer: 8 BCM SG_ TotalDistance : 0|32@1+ (0.125,0) [0|526385151.875] "km" ECU”
“100#803E5A0000000000 --- BO_ 256 EngineData: 8 ECU SG_ EngineSpeed : 0|16@1+ (0.125,0) [0|8031.875] "rpm" ABS SG_ CoolantTemp : 16|8@1+ (1,-40) [-40|215] "degC" ABS VAL_ 256 CoolantTemp 0 "Sensor fault" 255 "Not available" ;”
“7DF#02010C0000000000 --- BO_ 256 EngineData: 8 ECU SG_ EngineSpeed : 0|16@1+ (0.125,0) [0|8031.875] "rpm" ABS SG_ CoolantTemp : 16|8@1+ (1,-40) [-40|215] "degC" ABS VAL_ 256 CoolantTemp 0 "Sensor fault" 255 "Not available" ;”
“100#803E5A00000000000 --- BO_ 256 EngineData: 8 ECU SG_ EngineSpeed : 0|16@1+ (0.125,0) [0|8031.875] "rpm" ABS SG_ CoolantTemp : 16|8@1+ (1,-40) [-40|215] "degC" ABS VAL_ 256 CoolantTemp 0 "Sensor fault" 255 "Not available" ;”
“100#803E5A0000000000 --- VERSION "1.0"”
Reading the Decoded Output
Each decoded frame follows the same shape, so a long capture is easy to scan once you know what each part of a line tells you.
The Heading Line
Line number from your input, the identifier as candump prints it, the DBC message name, and how many data bytes the frame carried.
Signal Lines
One indented line per signal, in the order the DBC lists them, with the scaled value and its unit.
Labels in Brackets
When a value table names the raw value, its label follows in brackets, such as Not available for a raw 255.
Unknown and Remote Frames
Identifiers the DBC lacks get a one-line note, and remote requests say they carry no data, so nothing is silently dropped.
Frame Formats This Decoder Reads
SocketCAN tools write frames several ways. These ten notes cover the formats and what each part means.
123#DEADBEEF
cansend and candump -L syntax: hex identifier, a hash, then the data bytes with no spaces.
“How many bytes is DEADBEEF?”
Three-Digit IDs
Standard 11-bit identifiers are written with three hex digits, up to 7FF.
“What’s the largest standard ID?”
Eight-Digit IDs
Extended 29-bit identifiers are written with eight hex digits, up to 1FFFFFFF.
“How is an extended ID written?”
123#R
A remote transmission request: no data, just a request for the frame.
“Does a remote frame carry data?”
123##1…
CAN FD: two hashes, a flags nibble, then up to 64 data bytes.
“What follows the double hash?”
Log Lines
candump -l writes (timestamp) interface then the frame, for example (1698912345.12) can0 100#80.
“Which flag writes log files?”
Default Output
Plain candump prints interface, ID, [length] and spaced bytes.
“What’s in the brackets?”
Spaced Bytes
An ID followed by bytes with spaces also works, as copied from many tools.
“Are spaces allowed?”
DLC
The data length code says how many bytes follow, 0 to 8 in classic CAN.
“What’s the classic CAN maximum?”
CAN FD Lengths
CAN FD allows 12, 16, 20, 24, 32, 48 and 64 bytes as well.
“What’s the CAN FD maximum?”
Capturing Frames With can-utils
Most logs pasted here come from the Linux can-utils package. These commands produce output in exactly the formats the decoder reads, so you can go from a live bus to decoded values in a minute.
Bring the Interface Up
Run ip link set can0 up type can bitrate 500000 first. The bitrate must match the bus, or you will see error frames and nothing else.
candump can0
Prints every frame with interface, identifier, length and spaced bytes. Paste a few lines straight in.
candump -l can0
Writes a log file named after the start time, with a timestamp on every line. Open it here with Open log.
candump -L can0
Prints the same compact log format to the terminal instead of a file, handy for copying a short burst.
Filter by ID
candump can0,100:7FF shows only identifier 0x100. Filtering keeps a busy bus readable while you test one message.
cansend
cansend can0 100#803E5A0000000000 sends one frame. The text after the interface is the same syntax this decoder takes.
canplayer
Replays a candump -l log onto a bus, so a capture decoded here can be played back to a test ECU.
How a Signal Becomes a Value
Decoding a signal takes the same steps every time. These explain what happens between the raw bytes and the number you read.
Find the Message
The frame’s identifier is matched to a BO_ message in the DBC. No match means the frame isn’t described.
Pick the Bits
Each signal’s start bit, length and byte order say which payload bits to read, and in what order.
Apply the Sign
Signed signals are read as two’s complement, so the top bit makes the value negative.
Scale and Offset
The physical value is raw times factor plus offset, so 16,000 × 0.125 + 0 is 2,000 rpm.
Look Up Labels
If a value table names the raw value, such as 255 for not available, the label is shown too.
Respect Multiplexing
Multiplexed signals only apply when the multiplexor holds their value, so others are skipped.
Decoding Pitfalls
When decoded values look wrong, one of these is usually why.
The Wrong DBC
Manufacturers reuse IDs across models and years. A DBC for another vehicle decodes plausible but wrong numbers.
Byte Order Flipped
A value that looks byte-swapped usually means @0 and @1 are mixed up in the DBC.
Not-Available Values
All-ones bytes often mean the data isn’t available. Check the value table before trusting them.
Missing Extended Flag
An extended frame won’t match a DBC message that lacks bit 31 in its ID, and vice versa.
Diagnostic Traffic
Frames such as 7DF and 7E8 are OBD-II diagnostics, which a vehicle DBC rarely describes.
Short Frames
If a frame carries fewer bytes than the DBC says, signals beyond its end are skipped.
Where the DBC Comes From
A decoder is only as good as the database behind it. These are the usual sources, from the most trustworthy to the most guesswork, and what to expect from each one when you paste it in.
Your Own Project
If you build the ECU, the DBC is the specification. Decode against it to prove the firmware matches.
The Vehicle Manufacturer
OEM databases come under NDA with suppliers. They are complete and correct but cannot be shared.
J1939 Databases
Trucks, tractors and generators share SAE J1939 parameter groups, so one J1939 DBC covers many machines.
Community Files
Projects such as opendbc publish reverse engineered DBC files for many cars, with varying coverage.
Adapter Vendors
Logger and dongle makers often ship DBC files for common vehicles, especially for OBD-II and J1939.
Reverse Engineering
Without any of these, you capture traffic, change one thing on the vehicle, and watch which bits move.
When to Decode CAN Frames
Whenever you have bytes from a bus and need the values behind them.
Checking a Log
Decode a candump capture from a test drive to see speeds, temperatures and states.
Debugging Firmware
Compare what your ECU sends with what the DBC says it should send.
Reverse Engineering
Test a guessed signal definition against real frames before writing it into the DBC.
Bug Reports
Turn a few lines of raw traffic into readable values for a ticket.
Learning CAN
See exactly how bytes become values with the raw and physical views side by side.