Big Endian vs Little Endian: Byte Order Explained

Big endian vs little endian is the question of which byte of a multi-byte value comes first in memory or on the wire. A big-endian system stores the most significant byte at the lowest address; a little-endian system stores the least significant byte there. The numeric value does not change, only its byte layout. Read raw bytes with the wrong rule, and a valid 32-bit integer turns into a different number.

What endianness changes in memory

Endianness is the order of bytes within a word-sized data type, ranked by significance. The most significant byte (MSB) carries the highest place value, the least significant byte (LSB) the lowest. Big endian puts the MSB at the lowest address, little endian puts the LSB there. The rule only matters when a value occupies more than one byte; a single byte has no ordering problem.

Think of a 32-bit integer as four bytes. Hexadecimal notation writes it with the most significant part on the left and the least significant part on the right. Memory addresses, however, simply count upward. Endianness defines how those two sequences line up.

See the same 32-bit value in both byte orders

Take the value 0x12345678. Its four bytes are 0x12, 0x34, 0x56, and 0x78. Both machines hold the same integer; they just lay out its bytes differently.

You can print the layout on your own machine. On an x86 or a typical ARM system, this program shows the little-endian column:

#include <stdint.h>
#include <stdio.h>

int main(void) {
    uint32_t value = 0x12345678;
    const unsigned char *p = (const unsigned char *)&value;

    for (int i = 0; i < 4; i++)
        printf("address +%d: 0x%02X\n", i, p[i]);
    return 0;
}

Text makes the effect easy to see. Pack the letters “J O H N” into one 32-bit word: a big-endian memory view shows them in that left-to-right order, while the same word viewed on a little-endian machine reads “N H O J.” The name is unchanged; only the byte view differs.

Where the names big endian and little endian come from

Danny Cohen introduced the terms in 1980 in Internet Experiment Note 137, “On Holy Wars and a Plea for Peace.” He borrowed them from Jonathan Swift’s Gulliver’s Travels (1726), in which the people of Lilliput and Blefuscu go to war over whether to crack an egg at the big end or the little end. Cohen used the satire to mock the equally stubborn dispute between computer designers over byte order.

Why Intel uses little endian

Intel x86 and x86-64 (including AMD64) are little-endian. The roots go back to the Intel 8008 of 1972, which kept the byte order of the bit-serial Datapoint 2200 for compatibility. A bit-serial machine has to process the LSB first. Intel kept that order even though Datapoint never used the 8008.

Most machines today are little endian mainly because x86 and ARM dominate PCs and smartphones. ARM processors are bi-endian, so they can run in either mode, but most Linux distributions for ARM use little endian by default. PowerPC is also bi-endian. The Motorola 68000 series, IBM System/360/370 and z/Architecture, and OpenRISC are big-endian only.

What little-endian ordering makes easier

With little endian, a value keeps the same address whether software reads its low-order part as an 8-, 16-, or 32-bit quantity, so such narrowing casts can be a no-op. Addition and subtraction also start at the least significant byte. On a narrow memory bus, such as the 8-bit data bus of the 8088, the processor can start computing on the low-order byte while the higher-order bytes are still loading.

These are design advantages, not proof that big endian is wrong. Big endian matches the way people write numbers, with the most significant digits first. The right choice is always the format the processor, protocol, or file requires.

Network byte order settles the wire format

TCP/IP uses big endian as its network byte order. This shared convention lets hosts with different native byte orders exchange multi-byte integers, as long as each side converts at the boundary. On POSIX systems, htonl() converts an unsigned 32-bit integer from host order to network byte order, and ntohl() converts it back. htons() and ntohs() do the same for 16-bit values.

#include <arpa/inet.h>
#include <stdint.h>
#include <stdio.h>

int main(void) {
    uint32_t host_value = 0x12345678;
    uint32_t wire_value = htonl(host_value);   /* host order -> network order */
    uint32_t back       = ntohl(wire_value);   /* network order -> host order */

    printf("0x%08X -> 0x%08X\n", (unsigned)host_value, (unsigned)back);
    return 0;
}

On a little-endian host these functions swap the bytes; on a big-endian host they do nothing. Leaving them out can look harmless while two x86 systems test against each other, then produce wrong values as soon as a big-endian system receives the data.

Files need their own declared byte order

A file format either fixes one byte order or declares it in a header. TIFF marks little endian with the first two bytes “II” (0x4949) and big endian with “MM” (0x4D4D). BMP stores its integer fields in little-endian format. ELF binaries carry an explicit EI_DATA header entry for endianness. In UTF-16 text, the byte order mark U+FEFF appears as the bytes FE FF in UTF-16BE and as FF FE in UTF-16LE.

This is why writing an in-memory C struct straight to a file is not a portable way to store data. Its byte order depends on the architecture, and padding adds another variable. A defined binary format with explicit conversion gives every reader the same interpretation.

Detect and convert the order at the boundary

To check at runtime in C, store the integer 1 and look at its first byte. If that byte is 1, the machine is little endian; otherwise it is big endian.

#include <stdio.h>

int main(void) {
    unsigned int x = 1;
    int is_little_endian = *(unsigned char *)&x == 1;

    printf("%s-endian\n", is_little_endian ? "little" : "big");
    return 0;
}

C++20 adds std::endian for a compile-time test. GCC and Clang provide __builtin_bswap16(), __builtin_bswap32(), and __builtin_bswap64() to reverse bytes. Swap only where a defined external format differs from host order, never as a guess applied to every integer.

Three endianness myths that cause bugs

• “Endianness reverses bits.” It changes the order of bytes. The bits inside each byte stay in place.
• “All data on one computer has one order.” The Intel 8051 expects the 16-bit addresses of LJMP and LCALL in big-endian format but pushes return addresses onto its stack in little endian.
• “A binary dump is portable.” The classic NUXI problem shows why it is not: the string “UNIX,” stored as two 16-bit words, reads U N I X on a big-endian machine and N U X I after a byte-order mix-up.

Frequently Asked Questions

What is the difference between big endian and little endian?

Big endian places the most significant byte of a multi-byte value at the lowest address. Little endian places the least significant byte there. The value is identical as long as it is read with the correct order.

Does Intel use big or little endian?

Intel x86 and x86-64 processors use little endian. Atom processors and Intel Core processors from the 4th generation onward also have the MOVBE instruction, which loads or stores big-endian data without a separate byte swap.

Can endianness cause compatibility issues between systems?

Yes. If a big-endian system sends multi-byte binary data to an x86 system without conversion, every value larger than one byte is misread. Network byte order and explicit file headers prevent that ambiguity.

How can you determine a system’s endianness?

In C, inspect the first byte of an integer whose value is 1. In C++20, compare std::endian::native with std::endian::little or std::endian::big.

Can data be converted between big endian and little endian?

Yes. Byte swapping reverses the bytes of a 16-, 32-, or 64-bit value. Network helpers such as htonl() and ntohl() make the conversion explicit for 32-bit integers.