DBC compare: find the edits that change decoding
DBC compare shows which messages and signals changed between two DBC files, old value over new.
Add a .dbc on each side. The comparison starts by itself.
When to compare DBC files
A DBC is the contract between the ECUs on a bus. Run a DBC compare whenever that contract changes hands.
A supplier sends a new release
The file arrives with a new version number and no change log. See every message and signal that moved before it goes into the integration branch.
A log stops decoding correctly
After a DBC update a signal reads twice what it should. Filter to Decoding and check factor, offset, start bit and byte order first.
A change request needs review
Paste the Markdown summary into the ticket or merge request, so reviewers see field-level changes with line numbers instead of a wall of text diff.
Two variants or two branches
Compare the DBC of two vehicle variants to see which IDs, DLCs and cycle times differ before you share test scripts or a decode setup between them.
What DBC compare checks, field by field
Each row lists the DBC statements the comparison reads, the fields it compares and the label a change gets.
| Object | Statements | Fields compared | Label |
|---|---|---|---|
| Message identity | BO_ | Frame type (standard or extended, bit 31) and arbitration ID are the match key. A new name on the same ID is a rename. | Description |
| Message properties | BO_ · BA_ | DLC, transmitter, GenMsgCycleTime, VFrameFormat | Timing |
| Added or removed | BO_ · SG_ | Whole messages, and signals inside a matched message | Coverage |
| Signal layout | SG_ · SIG_VALTYPE_ | Start bit, length, byte order (@0 Motorola, @1 Intel), signed or unsigned, IEEE float type, multiplexer (M, mN) | Decoding |
| Scaling | SG_ | Factor and offset, compared as numbers, so 0.10 and 0.1 are equal | Decoding |
| Range and unit | SG_ | Declared minimum and maximum; unit text | Timing · Description |
| Value tables | VAL_ | Every value and its label, matched by the raw number, not by line order | Description |
| Comments and receivers | CM_ · SG_ | Message and signal comments, receiving nodes as a set | Description |
| Attributes | BA_ | Message and signal attribute values by attribute name | Description |
| Not compared | SG_MUL_VAL_ · … | Extended multiplexing and statements the parser does not keep. They are listed by line, and the result is marked partial. | Partial |
A DBC diff by field, not by line
A plain text diff of two DBC files marks every line that moved. DBC compare reads both files into messages and signals and compares them field by field, so a moved block, new spacing or a reordered statement is not a change, and a changed factor is never lost in a wall of red and green.
Illustrative files: one message block moved, one line re-spaced, one factor changed.
How the DBC file comparison matches messages
A message matches on frame type and arbitration ID. A signal matches on its name inside that message. Anything less sure is only a candidate.
The same frame type and the same arbitration ID are one message, even when the name changed.
A name change on the same ID is reported as a rename. An ID change is not merged on the name alone.
Inside a matched message, signals match by name. The same layout under a new name is only a candidate.
Duplicate IDs or names are not paired. Both sides stay listed, with their lines.
What partial means
Something was not compared: a parse gap, a duplicate, or syntax this page does not interpret. The page will not say the files match.
Technical details
What DBC compare does with your files, and where it stops.
- File size
- Up to 150 MB per file. Both files are read into the memory of this tab.
- Encoding
- UTF-8, GBK and GB18030 are detected for each file, so Chinese comments and value labels compare as text.
- Matching
- Messages are paired by frame type and arbitration ID, signals by name inside the message. Line numbers start at 1 and come from each original file.
- IDs
- Shown in hex and decimal. The extended flag (bit 31) is removed for display; standard 0x123 and extended 0x123 stay separate messages.
- Export
- CSV with one row per change, warning and candidate, and a Markdown summary for tickets. Both carry the two file names, the compare time and the coverage status.
- Privacy
- No upload, no account, nothing stored. Closing the tab clears both files.
- Keyboard
- J and K, or the arrow keys, move to the next and previous message.
- Not in scope
- Editing or merging DBC files, ARXML and LDF, and re-decoding a log with either file.
DBC compare FAQ
Does this upload the file?
No. DBC compare reads both files in your browser. Nothing is uploaded.
Why can a text diff lie?
Sorting, whitespace and comments change the text without changing the fields used for decoding. Two files can look different line by line and still decode the same way, or look similar after a factor has changed.
When is a rename not confirmed?
The same layout under a different signal name is only a candidate. It is not treated as a confirmed match, so the added signal and the removed signal both stay in the result.
What does partial mean?
Something was not compared. The page will not say the files match, even when the parts it did compare have no changes.
Does a factor change prove the log values changed?
No. It means the same raw value can decode to a different physical value. This page does not re-decode a log.
Are a standard ID and an extended ID with the same 11-bit number the same message?
No. A standard frame and an extended frame that share the 11-bit number are different messages, and they are not paired.
Why are some signals grey?
They did not change. They stay in the table so the whole message, and its bit layout, can be read at once. Untick “Unchanged signals” to hide them.
How large can the files be?
Up to 150 MB each. Most production DBC files are well under 5 MB. The comparison runs in this tab, so a very large pair can take a few seconds.
More free tools
The next job after this one, each on its own page.