The Checksum Calculator produces three labeled one-byte values for a given message — an XOR-8 block check character, a Modbus ASCII longitudinal redundancy check, and a raw byte-sum modulo 256 — and the FIX protocol's standard checksum is the third of those, the low eight bits of the arithmetic sum of every byte covered by the field. To calculate the checksum for a FIX message, open the Checksum Calculator, pick the input mode that matches how your bytes are stored, paste only the bytes the FIX specification assigns to the checksum field, and copy the sum-modulo-256 result as two lowercase hex digits. The calculator does not parse FIX tags, delimiters, or framing on your behalf, and it does not claim FIX compatibility; it simply exposes the explicit formula so you can verify the result against the FIX 4.x or FIX 5.x specification document yourself. Because FIX messages use SOH (0x01) between fields and tag=value pairs separated by that single control byte, treating the message as hexadecimal bytes is usually the cleanest way to avoid encoding ambiguity.
The Three One-Byte Values the Calculator Shows
Every run of the calculator processes the exact bytes you supplied and returns three distinct one-byte results. The first is the XOR-8 block check character (BCC), which starts at zero and XORs every selected byte into an eight-bit accumulator; because XOR is commutative, byte order does not change the value. The second is the Modbus ASCII longitudinal redundancy check (LRC), which adds every byte into an eight-bit field, discards any carry that leaves the byte, and then returns the two's complement of that sum. The third is the raw byte-sum modulo 256, which is the low eight bits of the ordinary arithmetic sum before the two's-complement step. The Modbus LRC and the raw sum always add to zero modulo 256, so seeing both values side by side makes it easy to spot which one a particular device actually expects.
| Algorithm | Starting value | Operation per byte | Final step | Typical use |
|---|---|---|---|---|
| XOR-8 BCC | 0x00 | XOR into accumulator | none | Vendor-specific serial frames; confirm against device doc |
| Modbus ASCII LRC | 0x00 | Add into accumulator, discard carries | Two's complement | Modbus ASCII messages, excluding ':' and CRLF |
| Sum modulo 256 | 0x00 | Add into accumulator, discard carries | none | FIX protocol CheckSum field; diagnostic for additive conventions |
The calculator does not pick one of these values on your behalf. It exposes all three with explicit labels so the byte interpretation, the algorithm, and the final transformation can be matched against the target specification line by line.
Choosing Text or Hex Input for the Message
In UTF-8 text mode the browser encodes the pasted string as UTF-8 before any byte is summed, so non-ASCII characters such as accented letters or emoji contribute several bytes each and the displayed byte count can easily exceed the visible character count. In hexadecimal mode you enter each byte as exactly two hex digits, with optional whitespace between bytes; prefixes such as 0x, commas, colons, dashes, odd nibbles, and comments are rejected rather than silently guessed. For a typical FIX message the hex path is almost always the safer choice because every field is tag=value<0x01>tag=value<0x01>..., and that embedded SOH byte can be lost or mangled if you paste the message through any tool that treats it as plain text. If you need a step-by-step walkthrough of the raw-byte perspective used here, the binary checksum guide covers the same calculator from that angle.
If your source FIX message is already a clean ASCII string with no real risk of encoding drift, text mode is fine and lets you paste without manually converting each field to hex. The only safe rule is: if the bytes contain anything outside plain printable ASCII — including the 0x01 SOH separator, embedded nulls, or non-ASCII characters from a long FIX field — switch to hex mode and enter the bytes as pairs of hex digits so the calculator sees exactly what the receiver will see.
Calculate the FIX Message Checksum
The FIX specification defines the CheckSum field (tag 10) as the modulo-256 sum of every byte from the first character after the BeginString field up to the SOH byte that immediately precedes the CheckSum field itself. Because that definition maps directly onto the calculator's "Sum modulo 256" value, the procedure below is enough to produce a usable result.
- Open the Checksum Calculator and select Hex input mode for any FIX message that contains SOH (0x01) separators or non-ASCII characters; switch to Text only if your bytes are guaranteed printable ASCII.
- Assemble the byte sequence the FIX spec assigns to the checksum: from the first byte after the SOH following BeginString (tag 8) through the SOH that precedes tag 10. Omit the "10=" tag and its value, and omit the final SOH of the message.
- Convert that byte sequence to hexadecimal. Write each byte as exactly two hex digits, with single spaces between bytes for readability. Do not include 0x prefixes, commas, colons, dashes, or comments — those are rejected by the parser.
- Paste the hex into the calculator's input field and run the calculation. The page reports the exact number of bytes processed alongside the three results so you can confirm your byte count matches the FIX spec before trusting any value.
- Read the Sum modulo 256 result. Express it as exactly two lowercase hex digits (the calculator already does this, including any leading zero), and place it after "10=" in the FIX message followed by the final SOH.
- Verify on the receiver side: take every byte from after "8=" through the SOH before "10=", sum them modulo 256, and confirm the result equals the value placed in tag 10.
As a worked example, take the ASCII bytes for "HELLO", which are 48 45 4c 4c 4f. Adding them gives 72 + 69 + 76 + 76 + 79 = 372, and 372 mod 256 = 116, which is 0x74. The XOR-8 BCC for the same five bytes is 0x42 (0x48 ^ 0x45 = 0x0D; 0x0D ^ 0x4C = 0x41; 0x41 ^ 0x4C = 0x0D; 0x0D ^ 0x4F = 0x42). The Modbus ASCII LRC is the two's complement of 0x74, which is 0x8C. Confirming 0x74 + 0x8C = 0x100, the sum and the LRC add to exactly one byte rollover, as the algorithm guarantees.
Matching the Calculator Output to the FIX Specification
Different protocols that use the words "checksum" or "BCC" mean different things by them, so the only safe cross-check is to read the target specification and confirm four points: which bytes belong to the checksum, what the initial value is, what arithmetic is performed, and whether a final transformation is applied. The table below summarises the canonical definitions for the formulas this calculator implements; the FIX row matches the calculator's "Sum modulo 256" output, and the Modbus ASCII row matches the calculator's "Modbus ASCII LRC" output.
| Protocol | Bytes covered by the checksum | Framing excluded | Output transformation |
|---|---|---|---|
| FIX 4.x / 5.x CheckSum | All bytes from after "8=" through the SOH before "10=" | BeginString itself; tag 10 and its value | Sum mod 256 |
| Modbus ASCII LRC | All bytes between ':' and CRLF | Leading ':' and trailing CRLF | Two's complement |
| Vendor BCC (XOR-8) | Per vendor documentation | Per vendor documentation | None (XOR only) — see BALTECH XOR-8 reference |
If your device documentation describes a CRC-16, CRC-32, Fletcher, Adler, Internet checksum, or any named cryptographic hash, none of the three values produced here will match what the device expects, even though the words "checksum" or "BCC" may appear in the manual.
Limits, Error Handling, and Security Boundaries
The calculator processes at most 500,000 bytes per run and will not silently truncate longer input; the output panel reports the actual byte count so an oversize paste fails loudly rather than producing a quietly wrong answer. Malformed hexadecimal — odd nibbles, stray prefixes, stray separators, comments — is rejected as a whole and no partial value is shown, which keeps a single bad paste from being mistaken for a real checksum. Each result is always rendered as exactly two lowercase hex digits, including a leading zero, so the output can be pasted directly into a FIX tag without case-sensitivity problems on the receiver side.
None of the three values is a cryptographic hash, a message authentication code, a digital signature, encryption, or proof of origin. XOR and additive checksums have many collisions — many distinct inputs share the same one-byte value — and an attacker who controls the payload can adjust a byte to keep the sum unchanged. Do not rely on a one-byte checksum to protect credentials, to authorise FIX orders, to verify software downloads, or to authenticate any message that crosses an untrusted network. Use the security mechanism required by the actual FIX session layer or transport — for example TLS, signed FIXML, or a hardware security module — rather than treating field 10 as a tamper detector.
When This Calculator Is the Wrong Tool
Reach for a different tool the moment the target specification names anything wider, more structured, or cryptographically stronger than the formulas implemented here. CRC-16/Modbus, CRC-32/ISO-HDLC, Fletcher-16, Adler-32, the one's-complement Internet checksum used in TCP and IPv4 headers, and any SHA-2 family digest are all out of scope; the calculator does not implement them and will not guess them from context. If your FIX deployment requires a session-level integrity check beyond the built-in tag 10, look at a dedicated CRC or hash tool — the CRC checksum guide explains how to recognise that situation and switch to a CRC calculator.
The same applies if you need to check the integrity of a downloaded file, a firmware image, or a software package. A one-byte additive checksum has too many collisions to catch intentional tampering; a published SHA-256 digest from the vendor is the minimum appropriate integrity check in that case. Reserve the Checksum Calculator for the narrow, well-defined job it is built for: reproducing one of three explicit one-byte formulas over a known byte sequence, and comparing the labeled result against the device's documented expectation.