Why container offsets are not memory addresses
Intel HEX and Motorola S-record files contain ASCII records, checksums, record types, and explicit load addresses. Two containers can have different line lengths or record ordering while describing identical target memory. Conversely, two raw binaries can have matching file offsets yet target different addresses. This comparator decodes each supported container into a sparse address-to-byte map before comparing it.
Formats and validation behavior
Intel HEX record lengths, checksums, extended segment/linear addresses, EOF placement, overlaps, and start addresses are checked before its bytes enter the comparison. Motorola S-record parsing reuses ToolQuill's strict S0–S9 validator, including checksums, count records, overlaps, address widths, and termination records. A raw binary contains none of that metadata, so its base address is a required assumption. Pasted raw bytes accept hexadecimal pairs only.
Read the four comparison states
Unchanged means both maps contain the same byte at that address. Changed means both contain a byte but the values differ. Only in A and Only in B represent mapped bytes absent from the other image; they are not assumed to be zero or FF. Gaps remain absent, so the tool never invents fill bytes merely to make a flat array.
Firmware boundary
This is a comparison report, not a flashing decision. It does not parse ELF sections, relocate code, disassemble instructions, identify calibration areas, verify signatures, validate secure boot, recognize a target MCU, or prove that either image is authentic, complete, compatible, bootable, or safe. Preserve the originals and follow the device/vendor recovery and programming process.
Frequently asked questions
Can I compare Intel HEX with an S-record or BIN file?
Yes. Each input is decoded independently, then compared by its resolved 32-bit addresses. For BIN, enter the actual load base used by the target.
Are Intel HEX checksums enough to prove a file is safe?
No. A record checksum detects certain transport or editing errors in that record. It does not authenticate the publisher, target device, firmware version, or behavior.
Why are some bytes “only” on one side instead of changed?
A changed byte requires both maps to define the address. When one container has no data record covering that location, the state is one-sided rather than a guessed comparison against zero or an erased-flash value.
Does similarity include empty address gaps?
No. Similarity is unchanged bytes divided by the union of addresses explicitly populated by either image. Large unmapped gaps do not inflate the score.
Validate one Motorola S-record in depth · Browse electronics tools · All ToolQuill tools