Every multi-byte number a computer stores has to answer a small, unglamorous question: which byte comes first? The value 0x1234 is two bytes, 0x12 and 0x34, and a machine has to put one of them at the lower memory address. There is no physically correct answer. Different processor families picked different conventions, and the terms we use for the two choices come from a joke about eggs.
The Lilliputians went to war over which end of an egg to crack
In 1980, engineer Danny Cohen was working on network protocol design and needed a way to talk precisely about byte ordering without describing it from scratch every time. He borrowed a pair of terms from Jonathan Swift's 1726 satire Gulliver's Travels, in a short paper called "On Holy Wars and a Plea for Peace." In the book, the tiny island of Lilliput is split by a bitter, decades-long conflict over which end of a boiled egg is correct to crack: the big end or the little end. Swift meant it as a jab at pointless religious and political wars fought over trivial distinctions. Cohen meant it as a joke about processor architects doing exactly the same thing over byte order, and it worked a little too well: the names stuck permanently.
Big-endian stores the most significant byte at the lowest memory address, the way you would naturally write the number down: 0x12 then 0x34. Little-endian stores the least significant byte first: 0x34 then 0x12. Neither is more correct. Motorola's 68000 family and, historically, IBM mainframes went big-endian. Intel's x86 line went little-endian, which is why it is the default most developers meet first. Many modern ARM cores, including the Cortex-M chips inside a huge share of today's microcontrollers, are technically bi-endian and can be configured either way, though little-endian is the overwhelmingly common default in practice.
Why a naming joke turns into a real bug
This would be pure trivia if byte order stayed inside one chip. It does not. The moment two systems exchange multi-byte data — over a network, over a serial bus, or across a memory-mapped register — both sides have to agree on the order, and nothing enforces that agreement automatically.
The clearest example is networking itself. RFC 1700 fixed big-endian as "network byte order" for TCP/IP decades ago, which is why C's htons() and ntohs() functions exist at all: they convert a little-endian host's numbers into network byte order before sending, and back again on receipt. Skip that conversion on a little-endian host and a port number or IP address field silently becomes a different number — not an error, just wrong, which is a much harder class of bug to catch.
Embedded and IoT development hits the same failure mode constantly, just with sensors instead of sockets. A lot of common I2C and SPI peripherals — accelerometers, pressure sensors, ADCs — document their raw output registers as big-endian, because the datasheet author's convention or the sensor's internal DSP core dictated it, while the microcontroller reading them (an ESP32, an STM32, most anything built around Cortex-M) is little-endian. Read two register bytes in the wrong order and a real, sane pressure or temperature value turns into a value that is off by orders of magnitude, or wraps to something absurd. Because the read itself succeeds — no I2C NACK, no SPI error, no fault the debugger flags — it looks like a sensor problem or a wiring problem, and teams spend hours reseating connectors and re-checking pull-up resistors before someone thinks to print the raw bytes and notices they are reversed. The fix is a one-line byte swap once you know to look for it: the expensive part is not knowing.
This is worth building into review habits rather than relearning per project. Any time firmware reads a multi-byte field across a boundary it does not fully control — a sensor register, a radio payload, a file format, a config blob shared with another device — check the datasheet or spec for its byte order explicitly, and do not assume it matches your MCU's native order just because everything compiled and nothing crashed.
The etymology outlived the hardware debate
The "holy war" framing turned out to be apt in one more way: which endianness is better was argued for years and never settled, because there is no universally correct answer — big-endian reads naturally in a hex dump, little-endian makes certain arithmetic operations marginally cheaper in hardware, and both claims are true and both are minor. What did settle, permanently, was the vocabulary. Forty-five years after a paper that was partly a joke, "big-endian" and "little-endian" are the standard technical terms in every processor manual, every network RFC, and every sensor datasheet — a rare case of satire becoming the official name for the thing it was mocking.
If your team is bringing up a new sensor, radio module, or cross-platform data format and the numbers coming back look scrambled rather than simply wrong, byte order is worth checking before anything else. Fluidwire works on exactly this layer of embedded and IoT development — from firmware and PCB bring-up through the cloud services devices talk to — for teams building connected hardware in the Philippines and beyond. If you are debugging a similar mismatch or planning a new device from scratch, get in touch or take a look at our embedded and IoT development services.
Top comments (0)