HEX Firmware Record Validator

Intel HEX Record Checksum Validator

Use this Intel HEX Record Checksum Validator to verify an Intel HEX record, calculate the expected checksum, check the byte count, decode the address and record type, inspect the data bytes, and generate a corrected record when the checksum is wrong.

✓ Intel HEX ✓ Checksum Validation ✓ Byte Count Check ✓ Record Type Decode ✓ Corrected Record
HEX
Validate Intel HEX Record
● Ready
Paste one complete Intel HEX record beginning with a colon. Spaces and line endings are removed automatically.
Intel HEX Validation Result
Record Status
Provided Checksum
Calculated Checksum
Byte Count
Address
Record Type -
Data Bytes -
Checksum Calculation -
Corrected / Normalized Record
-

What Is an Intel HEX Record Checksum Validator?

An Intel HEX Record Checksum Validator checks whether one textual Intel HEX record is structurally correct and whether its final checksum byte matches the checksum calculated from the record fields.

Intel HEX is a text-based representation of binary memory contents commonly used for microcontroller firmware, EEPROM programming, bootloaders, ROM images, device programmers, and embedded development tools.

Each Intel HEX line contains a byte count, address, record type, optional data, and checksum. The validator decodes these fields, confirms that the byte count matches the supplied data, recalculates the checksum, and reports whether the record is valid.

How to Use the Intel HEX Checksum Validator

Paste an Intel HEX record

Enter one complete record beginning with a colon character.

Check the byte count

The first byte after the colon specifies how many bytes should appear in the data field.

Decode the address and record type

The validator displays the 16-bit record address and interprets standard record types.

Calculate the checksum

All bytes from byte count through the final data byte are summed, then the two’s complement of the low 8 bits is calculated.

Compare the checksum

If the provided and calculated checksum bytes match, the Intel HEX record passes validation.

Intel HEX Record Format

Every Intel HEX record begins with a colon followed by hexadecimal fields. The core structure is:

:llaaaatt[dd…]cc Where: ll = byte count aaaa = 16-bit address tt = record type dd = data bytes cc = checksum

Binutils documentation describes Intel HEX data records using exactly these elements: colon header, byte count, load address, record type, data bytes, and checksum. :contentReference[oaicite:1]{index=1}

Intel HEX Fields Explained

Field Length Meaning Example
Start Code 1 character Colon marking the beginning of the record. :
Byte Count 1 byte Number of bytes contained in the data field. 10
Address 2 bytes 16-bit address or offset associated with the record. 0100
Record Type 1 byte Defines how the record should be interpreted. 00
Data Variable Zero or more bytes determined by the byte count. 214601...
Checksum 1 byte Two’s-complement checksum for the record. 40

Modern MCU programming documentation also describes these same six parts: start code, byte count, address, record type, data, and checksum. :contentReference[oaicite:2]{index=2}

How Is an Intel HEX Checksum Calculated?

The checksum is calculated from the binary values represented by the hexadecimal byte pairs in the record, beginning with the byte count and ending with the last data byte.

The start colon is not included. The checksum byte itself is not included when generating the expected checksum.

Conceptually: sum = byte_count + address_high + address_low + record_type + all_data_bytes Keep the low 8 bits: low = sum & 0xFF Calculate the two’s complement: checksum = (-low) & 0xFF Equivalent form: checksum = ((~low) + 1) & 0xFF

The Intel HEX checksum is defined as the two’s complement of the low byte of the sum of all decoded record bytes preceding the checksum. :contentReference[oaicite:3]{index=3}

Intel HEX Checksum Validation Rule

Another useful way to verify an Intel HEX record is to include the transmitted checksum byte in the sum.

For a valid record: (byte count + address bytes + record type + data bytes + checksum) mod 256 = 0

The complete byte sum therefore ends with an 8-bit value of zero when the checksum is correct. Intel HEX format documentation describes this same verification property. :contentReference[oaicite:4]{index=4}

Intel HEX Data Record Example

Consider the record preloaded into the validator:

:10010000214601360121470136007EFE09D2190140 Breakdown: Byte Count = 10 hex = 16 bytes Address = 0100 Record Type = 00 Data = 214601360121470136007EFE09D21901 Checksum = 40

The validator independently calculates the checksum from the byte count, address, type, and 16 data bytes. If the result is 0x40, the record is valid.

Intel HEX Record Types

The record type changes the meaning of the address and data fields. Standard Intel HEX files commonly use types 00 through 05.

Type Name Purpose
00 Data Record Contains memory data to be loaded at the specified address or offset.
01 End Of File Marks the end of the Intel HEX file.
02 Extended Segment Address Supplies a segment base used to extend addressing beyond 16 bits.
03 Start Segment Address Provides a start execution address in segment:offset form.
04 Extended Linear Address Supplies upper address bits used with subsequent data records.
05 Start Linear Address Specifies a linear execution start address.

Intel HEX parser implementations and MCU programming specifications recognize these standard record-type values. :contentReference[oaicite:5]{index=5}

What Is an Intel HEX EOF Record?

An End Of File record uses record type 01, contains no data bytes, and conventionally uses address 0000.

Standard EOF record: :00000001FF Fields: Byte Count = 00 Address = 0000 Type = 01 Checksum = FF

Binutils documentation shows the same form for the Intel HEX end record. :contentReference[oaicite:6]{index=6}

What Is an Extended Linear Address Record?

A type 04 Extended Linear Address record supplies upper address bits for subsequent data records. This allows Intel HEX files to represent addresses beyond the original 16-bit record address field.

Example: :020000040800F2 Meaning: Byte Count = 02 Address = 0000 Type = 04 Data = 0800 Checksum = F2

Programming specifications describe type 04 records as part of the Intel HEX format used when extended address information is necessary. :contentReference[oaicite:7]{index=7}

Why Byte Count Validation Matters

The first byte after the colon states exactly how many bytes must appear in the data field. A checksum could only be interpreted correctly if the record boundaries are known.

If the byte count says 10, the record must contain 16 data bytes, or 32 hexadecimal data characters. A different amount of data indicates a malformed or truncated record.

This validator checks both checksum correctness and data-length consistency. That catches records where the checksum field might otherwise be parsed at the wrong position.

Intel HEX Address Field

Each record contains a four-hex-digit address field representing a 16-bit address or offset. For a simple data record within a 64 KiB address range, this value identifies the load address directly.

When extended address records are present, the effective address is formed using additional address information supplied by type 02 or type 04 records. A single-record validator can decode the local 16-bit address but cannot infer the complete effective address without the surrounding file context.

Why an Intel HEX Checksum May Fail

Modified Data Byte

Changing one firmware byte changes the record sum and therefore the expected checksum.

Wrong Byte Count

If the length field does not match the amount of data, the record is malformed.

Truncated Record

A copied or transmitted line may lose characters from the data or checksum.

Incorrect Address

The two address bytes participate in the checksum, so changing the address also changes the checksum.

Wrong Record Type

The record type byte contributes to the checksum calculation.

Manual Editing

Editing an Intel HEX line without recalculating its checksum causes validation to fail.

Intel HEX Checksum vs CRC

The Intel HEX record checksum is not a CRC. It is an 8-bit additive checksum formed by taking the two’s complement of the low byte of the record sum.

CRC algorithms instead use polynomial arithmetic. A CRC-8 calculation will therefore not reproduce the Intel HEX checksum even though both results occupy one byte.

Intel HEX vs Raw Binary Firmware

Intel HEX

Text representation containing hexadecimal characters, addresses, record types, byte counts, and per-record checksums.

Raw Binary

Contains the actual byte values directly and normally does not contain Intel HEX text record metadata.

Converting an Intel HEX file to raw binary requires parsing record addresses and types, not merely removing colons and checksum characters.

Where Intel HEX Records Are Used

Microcontroller Firmware

Programming tools commonly use HEX files to represent compiled flash-memory images.

Bootloaders

Bootloader utilities can parse Intel HEX records and program memory at the specified addresses.

EEPROM Programming

HEX records can transport addressable configuration and nonvolatile-memory data.

Firmware Debugging

Checksum validation helps detect damaged, manually edited, or truncated records.

Manufacturing

Device programming workflows frequently consume textual firmware image files.

Embedded Development

Engineers inspect record addresses, types, checksums, and data during programming-tool troubleshooting.

Common Intel HEX Validation Mistakes

Including the colon in the checksum

The colon is a textual start marker and is not one of the bytes added during checksum generation.

Summing ASCII character codes

Decode hexadecimal pairs into byte values first. The characters “1” and “0” represent byte 0x10, not ASCII values 0x31 and 0x30.

Forgetting the address bytes

Both high and low address bytes participate in the checksum.

Ignoring record type

The record-type byte is part of the checksum sum.

Ignoring byte count

The first record byte is included in the checksum and determines the expected data length.

Using only one’s complement

Intel HEX requires two’s complement, equivalent to invert-plus-one on the low 8-bit sum.

Intel HEX Record Checksum Validator FAQs

What is an Intel HEX record?
It is one line of an Intel HEX firmware file containing a byte count, address, record type, optional data bytes, and checksum, preceded by a colon.
How is an Intel HEX checksum calculated?
Add the byte count, two address bytes, record-type byte, and all data bytes. Take the low 8 bits of that sum, then calculate its two’s complement.
Is the colon included in the Intel HEX checksum?
No. The colon is a start marker and does not participate in the checksum sum.
Is the checksum byte included when generating the checksum?
No. Generate the checksum from byte count through the last data byte. For verification, including the checksum should make the final low-byte sum equal zero.
What does record type 00 mean?
Type 00 is a data record containing bytes to be loaded at the specified address or effective address.
What does record type 01 mean?
Type 01 is the End Of File record.
What does record type 04 mean?
Type 04 is an Extended Linear Address record used to supply high address bits for subsequent data records.
What is the standard Intel HEX EOF record?
A commonly used EOF record is :00000001FF.
Why is my Intel HEX checksum invalid?
A data byte, byte count, address, record type, or checksum may have been changed, lost, mistyped, or truncated.
Does this tool check the byte count?
Yes. The declared byte count must match the number of data bytes present in the record.
Is Intel HEX checksum the same as CRC-8?
No. Intel HEX uses an additive two’s-complement checksum, while CRC-8 uses polynomial arithmetic.
Can this validator fix an incorrect checksum?
Yes. If the rest of the record is structurally valid, the tool generates a normalized version containing the correctly calculated checksum.
Can I validate an entire Intel HEX file here?
This page is focused on validating one Intel HEX record at a time. It does not reconstruct or validate address relationships across an entire multi-record firmware file.
Does an Intel HEX checksum detect every possible error?
No checksum guarantees detection of every possible corruption. Intel HEX uses a simple 8-bit additive checksum primarily for record integrity checking.
Does the Intel HEX record address always equal the full memory address?
Not necessarily. Extended Segment Address or Extended Linear Address records can supply additional upper address information.

Validate Intel HEX Records Instantly

Paste an Intel HEX firmware record, verify its byte count and checksum, decode its address and record type, inspect the data bytes, and generate a corrected record directly in your browser.

Scroll to Top