Skip to content
100% local

Intel HEX parser

Validate Intel HEX records and extract their data as a hex dump.

Input
Output

Intel HEX parser

Paste an Intel HEX file — the ":10010000214601360121470136007EFE09D2190140" style records compilers and programmers produce for microcontrollers, EEPROMs and other embedded targets — and this tool checks every record's structure and checksum, then extracts the data bytes as a hex dump. It's built for firmware work: verifying a .hex file from a vendor before flashing it, checking a build for a corrupted record after a bad merge, or reading raw bytes without opening a hex editor.

Each line is parsed as one record: a byte count, a 16-bit address, a record type (data, end-of-file, or one of the segment/linear address and start records), the data bytes, and a checksum. A record is valid when its byte count matches the data present, its record type is recognized with the right length for its kind, and the sum of every byte in the record comes out to zero modulo 256 — the standard Intel HEX rule. Data bytes from every valid data record are concatenated in file order and rendered as a classic hex dump: an offset column, sixteen bytes per row, and a printable-ASCII gutter on the right.

Below the dump, a validation report lists every record that failed, by line number, tagged as either a malformed structure (a line that isn't well-formed hex, has a byte count that doesn't match its length, or an unrecognized record type) or a bad checksum. One broken line doesn't stop the rest of the file: every other record is still checked and, where valid, still contributes its bytes. Turn on "Uppercase hex" to render the dump with A–F instead of a–f, matching what your programmer or disassembler expects.

Everything runs in your browser. Firmware images and EEPROM contents are often proprietary, so nothing pasted here is uploaded — the file never leaves your device.

FAQ

What counts as a bad checksum versus a malformed record?
A malformed record is one whose structure is broken: it doesn't start with ":", isn't valid hex, its byte count doesn't match its actual length, or its record type isn't recognized. A record with valid structure but a checksum that doesn't sum to zero mod 256 is reported separately as a bad checksum — its data is still extracted, since the bytes themselves are well-formed.
Which record types does it understand?
Data (00) and end-of-file (01), plus the extended segment address, start segment address, extended linear address and start linear address records (02–05). Only data records contribute bytes to the output; the others are validated for structure but carry no output data.
How are the data bytes laid out in the output?
They are concatenated in the order their records appear in the file, not placed at their record addresses — the output is the raw data stream, not a memory image.
Does one broken line stop the whole file from parsing?
No. Every record is checked independently, so a single malformed or bad-checksum line is listed in the validation report while every other valid record still parses and contributes its bytes.
Is my HEX file uploaded anywhere?
No. Parsing happens entirely in your browser — firmware and EEPROM contents you paste here are never sent to a server.