Protocol scope and method
Both inputs are normalized before comparison. Offsets are zero-based bytes.
difference at i when before[i] != after[i].
Diagnostic scenario
Normalize two redacted messages captured at the same protocol layer and align them to the same boundary. Compare changed offsets, then map each offset through the parsed header and length fields rather than assuming equal visual positions represent the same semantic field.
How to interpret the result
A byte insertion or optional field shifts every following raw offset and can create a large diff from one structural change. The tool reports byte differences but does not perform semantic alignment, checksum exclusion or encrypted-content interpretation.
Input reference
- Original hex
- Example default: Sample input included
- Updated hex
- Example default: Sample input included
Common mistakes
- Using an unredacted production capture with vehicle, credential or network identifiers.
- Comparing messages with different optional-field layouts as fixed records.
- Treating a successfully parsed sample as standards compliance or interoperability proof.
Before using the result
- Confirm the protocol edition, transport framing and vendor profile before interpreting fields.
- Align structural boundaries and exclude expected serial/check fields.
- Keep a redacted known-good and known-bad sample as a regression pair.
Questions to check during diagnosis
Does the Protocol Hex Diff leave my browser?
No application upload is used. Avoid putting sensitive production data in shareable URLs.
Is this a standards compliance test?
No. Confirm the edition and vendor profile with licensed documents and your target platform.
Offline diagnostic aid. Verify fields, version and vendor extensions before production use.