Byte Offset Calculator
Paste hex bytes and read them back as an indexed offset table — decimal and hex offsets, selectable grouping, and a printable-ASCII preview. Then pick any slice and see its unsigned and signed value in both little-endian and big-endian. Built for APDU, TLV, and binary-protocol debugging.
How to use this tool
What it does
Maps byte offsets within a hex buffer, with a printable-ASCII preview, so you can slice a field by position.
When to use it
Use it when a spec describes a structure by offset and length and you need to pull the right bytes out of a capture.
Worked example
Select offset 4, length 8 in a buffer to isolate an 8-byte serial number and see its ASCII rendering.
Input
Offset table
Interpret a slice as an integer
Integer value
What this tool does
A byte offset calculator answers the question every protocol engineer keeps asking while staring at a hex dump: which byte is at which position, and what does this run of bytes mean as a number? Paste a string of hex, and the tool produces a row-by-row table that pairs each group of bytes with its starting offset shown three ways — 0-based decimal, 0-based hexadecimal, and 1-based decimal — alongside a printable-ASCII rendering where any byte outside 0x20–0x7E appears as a dot. The total byte count is shown so you can confirm a length field at a glance.
Below the table, a second panel takes a start offset and a length and decodes that slice as an integer. It reports the unsigned value and the two's-complement signed value in both byte orders, using exact 64-bit arithmetic. Together the two panels turn a wall of hex into something you can navigate by position and read as values.
When to use it
Reach for it whenever you are debugging a length-prefixed or position-addressed binary structure. Typical cases: locating the Lc field and command data in an ISO 7816 APDU; confirming a two-byte SW1 SW2 status word; checking where a tag, length, and value sit inside a BER-TLV record; or reading a multi-byte counter or serial number out of a memory dump or NFC frame. Because grouping is selectable from 1 up to 16 bytes per row, you can line the view up with a 16-column hex editor or collapse it to one byte per row for fine-grained counting.
Input and output
The input is forgiving: it strips spaces, newlines, 0x prefixes, and : , ; separators before parsing, so traces copied from a card reader, a debugger, or a spec all work. The cleaned text must have an even number of hex digits and contain only 0–9 and a–f; anything else raises a specific inline error rather than guessing. The offset table output is plain monospaced text you can copy straight into a bug report. The integer panel echoes the exact slice it read, then the big-endian and little-endian values, so there is never ambiguity about which bytes produced which number.
Common mistakes
- Mixing up 0-based and 1-based offsets. Specs disagree; the table shows both, so quote the one your reference uses instead of converting in your head.
- Reading the wrong byte order. Smart-card and EMV fields are overwhelmingly big-endian, but many host-side and Intel-derived structures are little-endian. Check both — the panel always shows the pair.
- Forgetting the sign. A leading byte of
0x80or higher flips a signed interpretation negative. If a value looks impossibly large, read the signed column. - Slicing past the end. Asking for more bytes than remain raises an error rather than padding with zeros, so a bad length field is caught immediately.
- Pasting an odd number of digits. A dropped nibble shifts every byte after it; the even-length check stops that silently corrupting the table.
Related tools
TLV parser
Break a BER-TLV blob into tag, length, and value to see the structure behind the offsets.
Endianness converter
Flip byte order and view integers across widths in more detail.
Frequently asked questions
What input does the byte offset calculator accept?
Paste hex bytes in almost any common shape. Spaces, line breaks, 0x prefixes, colons, commas, and semicolons are all stripped before parsing, so 00A40400, 00 A4 04 00, and 00:A4:04:00 are equivalent. The cleaned string must contain an even number of hex digits; an odd count or a non-hex character produces a clear inline error.
Why does the table show both decimal and hex offsets?
Protocol specifications mix conventions. ISO 7816 and EMV tables usually count fields in decimal, while memory dumps and TLV traces label positions in hex. Showing 0-based decimal, hex, and 1-based decimal offsets side by side lets you match whichever the spec you are reading uses, without re-counting by hand.
How are the little-endian and big-endian integers computed?
You choose a start offset and a length of 1 to 8 bytes. The tool reads that slice most-significant-byte-first for big-endian and least-significant-byte-first for little-endian, then reports both the unsigned value and the two's-complement signed value. It uses JavaScript BigInt so 64-bit values stay exact rather than losing precision.
Does anything I paste leave my browser?
No. Parsing, the offset table, the ASCII preview, and all integer interpretation run locally in JavaScript on this page. Nothing is uploaded, logged, or sent to a server, so it is safe to inspect APDUs, keys, and other sensitive byte strings.
How do I use an offset table to locate a field in an APDU response?
Read the field's documented offset, then find that row in the table. The decimal and hex columns let you match specifications that use either notation without converting by hand.