When I first started embedded development, I wrote code to communicate with a PLC device over MODBUS RTU protocol and got the CRC calculation perfectly right. Yet the device kept refusing to respond. After days of troubleshooting, I found the culprit: the byte order of the 2-byte CRC value was reversed. I was sending 0x2B 0xA1 when I should have been sending 0xA1 0x2B. That is the endianness problem.

Endianness is far from a textbook abstraction. It exists quietly but lethally everywhere bytes are handled — network communication, file formats, embedded systems, cryptography, databases. If you ever need to compute a CRC value, you can use the CRC Tool.

What Is Endianness?

Endianness refers to the order in which a computer stores the bytes of multi-byte data in memory. When storing an integer that spans two or more bytes, there are two approaches depending on which byte goes first.

Consider storing the hexadecimal value 0x12345678 (a 4-byte integer) starting at memory address 0x1000.

Byte layout comparison for storing 0x12345678: big endian (left) vs. little endian (right).

Big Endian

The most significant byte (MSB) is stored at the lowest memory address first. This matches the way humans naturally read numbers. 0x12345678 is stored in order: 12 → 34 → 56 → 78.

The TCP/IP network standard (RFC 1700, now superseded by RFC 3232) defines big endian as the network byte order. Motorola 68000, SPARC, and PowerPC processors use this convention.

Little Endian

The least significant byte (LSB) is stored at the lowest memory address first. 0x12345678 is stored as 78 → 56 → 34 → 12.

This is the approach used by Intel x86, x86-64, and ARM (in its default configuration) — the architectures that power the vast majority of modern PCs and smartphones. Storing the low byte at the lowest address offers structural advantages for certain arithmetic operations.

Why Do Both Conventions Coexist?

Historically, the two approaches evolved independently in different camps. In 1980, Danny Cohen formally raised the debate in his paper "On Holy Wars and a Plea for Peace", drawing an analogy to Jonathan Swift's Gulliver's Travels, where wars are fought over which end of a boiled egg to crack first. His point: this is not a question of which side is superior, but a difference in design philosophy.

Most modern processors today support Bi-Endian mode, allowing software to select either convention. The ARM architecture, starting from ARMv3, is a prominent example.

When Endianness Problems Arise in Real Development

1. Network Communication (Socket Programming)

The reason C/C++ socket code uses htons(), htonl(), ntohs(), and ntohl() is precisely to perform endian conversion. You must convert the host byte order to network byte order (big endian).

uint16_t port = 8080;
struct sockaddr_in addr;
addr.sin_port = htons(port); // Host → Network byte order conversion

Skip this conversion on a little-endian x86 system and 0x1F90 (8080) gets transmitted as 0x901F, which the receiver interprets as a completely different port number.

2. File Format Parsing

Every file format has its own endianness convention. PNG uses big endian; BMP uses little endian. Ignore this when parsing files directly and metadata like file size, width, and height will be read as entirely wrong values.

3. MODBUS and Industrial Protocols

The MODBUS RTU protocol is fundamentally big endian — with one exception: the CRC field is transmitted in little endian (LSB first). Furthermore, how 32-bit registers are word-swapped can vary between devices, making endianness-related communication errors extremely common in industrial environments.

Why Endianness Is Critical in CRC Calculations

When computing a CRC checksum and inserting it into a communication frame, endianness is one of the most important factors to get right. For CRCs whose result spans two or more bytes — such as CRC-16 or CRC-32 — the order in which those bytes are placed in the frame completely determines whether the receiver's validation succeeds or fails.

For example, if the CRC-16/MODBUS result is 0x2BA1:

• Big endian: insert 0x2B 0xA1 into the frame
• Little endian: insert 0xA1 0x2B into the frame

The MODBUS RTU standard mandates little-endian CRC transmission. Misunderstanding this and sending big endian means the frame may be perfectly formed in every other way, yet the device will reject it as an invalid packet.

The CRC algorithm itself also handles endianness differently depending on whether bit reflection is applied. The CRC Algorithm Catalogue explicitly defines RefIn (reflect input bits) and RefOut (reflect output bits) parameters for each algorithm — essential reading during implementation.

To verify these endian behaviors hands-on, the CRC Tool is a practical resource. It supports over 100 CRC algorithms and lets you compare big endian and little endian results in real time, view byte-separated output, and switch between HEX, binary, and octal formats. It's particularly useful for validating protocol-specific CRC algorithms — MODBUS, CAN, Bluetooth, and more — by tweaking inputs and observing results immediately.

CRC Tool displaying CRC-16/MODBUS results in both big endian and little endian. The byte order reversal is clearly visible.

Practical Tips for Working with Endianness

Use Your Language's Built-In Facilities

Every major language provides standard tools for endian conversion. Using them is safer and more readable than rolling your own bit-manipulation logic.

import struct

value = 0x12345678

# Pack as big endian
big = struct.pack('>I', value)     # b'\x12\x34\x56\x78'

# Pack as little endian
little = struct.pack('<I', value)  # b'\x78\x56\x34\x12'

// C: network byte order conversion
#include <arpa/inet.h>
uint16_t host_val = 8080;
uint16_t net_val  = htons(host_val); // Little → Big Endian

// Rust: explicit endian conversion
let value: u32 = 0x12345678;
let be_bytes = value.to_be_bytes(); // [0x12, 0x34, 0x56, 0x78]
let le_bytes = value.to_le_bytes(); // [0x78, 0x56, 0x34, 0x12]

Debug at the Byte Level

When a communication error is suspected, always use Wireshark, a logic analyzer, or a custom HEX dump to inspect the actual byte sequence being transmitted. A value may look correct at a high level, yet be interpreted as something entirely different on the receiving end if the byte order is wrong.

Document Byte Order Explicitly

When designing a protocol or defining an interface, always specify byte order explicitly — for example, "this field is a big-endian 2-byte unsigned integer." Implicit assumptions will inevitably cause problems down the line.

Closing Thoughts

Endianness can seem like a trivial convention, but when two systems from different worlds exchange data and that convention breaks down, everything falls apart. In environments where devices from different manufacturers and architectures coexist — IoT sensors, industrial controllers, network equipment — a solid understanding of endianness is an essential skill.

After losing days to that first MODBUS communication bug, I now check byte order first whenever I design or analyze a protocol. Errors that arise at the intersection of CRC and endianness are especially hard to reproduce and diagnose. Tools like the CRC Tool, which let you flip endian settings and instantly see the effect on results, can dramatically speed up that diagnosis.

References and Further Reading

1. Danny Cohen, "On Holy Wars and a Plea for Peace", IEN 137, 1980 — The foundational paper that sparked the endianness debate. Later published in IEEE Computer Magazine (1981).
2. IETF RFC 1700, "Assigned Numbers" — Defines network byte order (big endian) as the standard. Superseded by RFC 3232.
3. Modbus Organization, "MODBUS Application Protocol Specification V1.1b3" — Official specification for MODBUS CRC and byte order.
4. Ross Williams, "A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS" — The definitive reference on CRC parameters and bit reflection.
5. CRC Catalogue, "Catalogue of parametrised CRC algorithms" — Per-algorithm parameter reference including RefIn/RefOut.