Intel HEX encoder
Address 256, type 0 and sixteen data bytes become the record :10010000214601360121470136007EFE09D2190140, with checksum 40 worked out for you. Paste existing lines to have every byte count and checksum verified before a bad image reaches a chip. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Calculation mode
- Encode
- Address
- 256
- Record type
- 0
- Data
- 214601360121470136007EFE09D21901
- Record count
- 1
Intel HEX is the text format most microcontroller toolchains still emit when you ask for a flashable image: every line starts with a colon, then a byte count, a sixteen-bit address, a record type, optional data bytes, and a two's-complement checksum that catches paste errors before a programmer burns bad data.
What one line of an Intel HEX file contains
Intel HEX is the text format most microcontroller toolchains still produce when you ask for a flashable image. Each line is one record: a colon, a byte count, a sixteen-bit load address, a record type, the data bytes and a final checksum. Type 0 carries ordinary data, type 1 marks the end of the file and carries no data, types 2 and 4 are extended segment and extended linear address records with exactly two data bytes, and types 3 and 5 are start address records with exactly four. Writing address 256, type 0 and sixteen data bytes produces the line :10010000214601360121470136007EFE09D2190140, where 10 is the byte count written in hexadecimal and 40 the checksum.
Why the checksum matters, and the usual slips
The checksum is the two's complement of the sum of every byte before it, so a single mistyped or lost digit makes the record fail before a programmer burns bad data into a chip. When you decode, each pasted line is checked: it must start with a colon, hold an even number of hex digits, have a byte count that matches the data actually present, use a type from 0 to 5 and end with the right checksum. Common slips are counting characters instead of bytes, forgetting that the address is limited to 0 through 65535, and pasting a line that lost its last two digits. Blank lines between records are simply ignored.
Decode lines, verify every checksum, and read the fields
Set mode to decode and place one or more Intel HEX lines in text, each beginning with a colon. Multi-line pastes are split on newlines; blank lines are ignored. For every non-empty line the parser checks that the body is even-length hex, that the byte count field matches the number of data digits present, that the record type is in zero through five, and that the final checksum byte equals the two's-complement of the sum of all prior bytes in the record.
Prefer decode when you need to explain what a vendor dump contains, when a student must show that a hand-computed checksum matches the file, or when a test harness must prove that an artifact still matches the published record after a transform.
What you can do with it
Lab and classroom checksum checks
Students paste Intel HEX lines, verify each checksum, and read type names without installing a vendor toolchain or risking a bad flash.
Support dumps and ticket review
Support engineers decode vendor .hex snippets to confirm load offsets and catch paste corruption before escalating to hardware.
FAQ
How do I encode an Intel HEX record?
The response records[0].line is the full colon record with a correct checksum.
How do I decode and verify Intel HEX lines?
Send mode decode and put one or more lines starting with ':' in text.
Which record types are supported?
Types 2 and 4 need 2 data bytes; 3 and 5 need 4; type 1 must be empty.
How is the Intel HEX checksum calculated?
It is the two's complement of the sum of every byte that comes before it on the line: byte count, address, type and data. That is why a single miscopied digit is enough to make the check fail.
Why is my pasted line rejected?
The line must start with a colon and hold an even number of hex digits. The declared byte count must match the data actually present, the type must be 0 to 5, and the last byte must be the correct checksum.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/enc/intel-hex \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"mode":"encode","direction":"encode"}'const res = await fetch("https://api.kit.forhosting.com/enc/intel-hex", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"mode": "encode",
"direction": "encode"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/intel-hex",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"mode": "encode",
"direction": "encode"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/intel-hex", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"mode":"encode","direction":"encode"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"mode":"encode","direction":"encode"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/intel-hex", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"mode": "encode",
"direction": "encode"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.intel_hex",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
This Intel HEX encoder builds a correct record from address, type, and hex payload, or parses one or more lines you already have, checking length against the declared byte count and rejecting any line whose checksum does not match.
Encode a firmware record with address, type, and checksum
Set mode to encode, or leave it at the default. The engine then assembles colon, byte count, address, type, data, and the two's-complement checksum of every preceding byte, and returns a records array with one object containing the full line, numeric and hex address, type name, data hex, and checksum. An empty data string is valid for end-of-file and for pure type-only experiments. Supply the sixteen-bit load offset in address as an integer from zero through sixty-five thousand five hundred thirty-five; values outside that range fail with invalid_input because the classic Intel HEX address field is only two bytes wide. Choose record_type from zero through five: zero is ordinary data, one is end of file with empty payload, two and four are extended segment and extended linear address records that carry exactly two data bytes, and three and five are start segment and start linear address records that carry exactly four data bytes. Put the payload in data as hexadecimal digits; optional spaces, colons, dashes, and zero-x prefixes are stripped, an odd digit count after cleanup is rejected, and more than two hundred fifty-five bytes is rejected because the length field is a single byte.
Decode lines, verify every checksum, and read the fields
Any failure raises invalid_input with a message that names the line number and the expected versus actual checksum when the math disagrees—those failures are not billed on the prepaid path. On success you receive mode decode, a records array in file order, record_count, and all_checksums_ok set to true. Each record object mirrors the encode shape: the normalized uppercase line, byte_count, address and address_hex, record_type and record_type_name, data hex, checksum, and checksum_ok. This contract is enough to audit a small .hex snippet without importing a full object-file toolchain, and it is strict enough that a flipped nibble in a ticket paste fails immediately instead of producing a silently wrong flash image.
Workflows, pricing, limits, and when to use this tool
Another workflow pastes a multi-line snippet that includes an extended linear address record and an end-of-file marker, confirming every checksum before a human approves a field update. This capability does not expand extended address records into a thirty-two-bit flat memory map and does not talk to a hardware programmer; pair it with your own flasher or map builder when you need full image assembly. Source text follows the same retention rules as other KIT parse items, and results are safe to pin because the algorithm is fully deterministic. Call the free in-browser Intel HEX encoder for lab demos, support tickets, and one-off checksum checks without installing srec_cat, objcopy, or a vendor IDE. Use the prepaid KIT API when a backend, edge worker, or SDK must encode or verify records under balance at $0.002 per successful item; validation errors never consume balance after the engine rejects the request. Keep payloads short enough for interactive use—record data is capped at two hundred fifty-five bytes by the format itself—and use dedicated binary upload tools for multi-megabyte production images.
Integration use cases
Firmware patch and CI goldens
Encode a short data record at a fixed offset, pin the line in continuous integration, and decode it later to prove address, payload, and checksum still match.
Technical questions
What happens if the checksum is wrong?
Decode fails with invalid_input naming the line and the expected versus actual checksum. Correct records return checksum_ok true and all_checksums_ok true.
What does the Intel HEX encoder cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.