Endianness: Big-Endian vs Little-Endian Explained

TL;DR: Endianness is the byte order used to store multi-byte values (like 32-bit integers or floats). Big-endian writes the most-significant byte first; little-endian writes the least-significant byte first. The term was coined by Danny Cohen (1980), riffing on Gulliver’s Travels’ “big-endians” vs “little-endians.”

Table of Contents

What is Endianness?

When a value needs more than one byte (e.g., 0x12345678), computers must choose an order:

Big-endian (BE): bytes stored as 12 34 56 78
Little-endian (LE): bytes stored as 78 56 34 12

If two systems disagree on byte order, the same number can look “backwards,” producing wrong values unless you swap the byte order.

Where did the term come from?

In 1980, Danny Cohen wrote “On Holy Wars and a Plea for Peace,” joking that the “byte-order wars” resembled the egg-cracking factions in Jonathan Swift’s Gulliver’s Travels: big-endians vs little-endians. The name stuck—and so did the bugs when engineers forget to convert byte order.

Why endianness matters (real-world)

Networking: “Network byte order” is big-endian. If your host is little-endian (Intel, most ARM), you must convert.
Binary files & protocols: BLE/USB frames, sensor packets, images, audio containers all define byte order. Misreading one float can turn 100.0 into nonsense.
Cross-platform data: Moving data between different CPUs/OSes? Convert or standardize.

Quick mental check: the IEEE-754 float 100.0 is 0x42C80000.

LE bytes: 00 00 C8 42
BE bytes: 42 C8 00 00

Quick examples

Read a 32-bit float from bytes

JavaScript

// bytes = Uint8Array of length 4
function bytesToFloat32(bytes, littleEndian = true) {
  const dv = new DataView(bytes.buffer, bytes.byteOffset, bytes.byteLength);
  return dv.getFloat32(0, littleEndian);
}

// Example: 100.0f in LE = [0x00, 0x00, 0xC8, 0x42]
console.log(bytesToFloat32(new Uint8Array([0x00,0x00,0xC8,0x42]), true));  // 100
console.log(bytesToFloat32(new Uint8Array([0x42,0xC8,0x00,0x00]), false)); // 100

Python

import struct

# LE float
print(struct.unpack('<f', bytes([0x00,0x00,0xC8,0x42]))[0])  # 100.0
# BE float
print(struct.unpack('>f', bytes([0x42,0xC8,0x00,0x00]))[0])  # 100.0

#include <stdint.h>
#include <string.h>

float bytes_to_float_le(uint8_t b[4]) {
    float f;
    uint8_t le[4] = { b[0], b[1], b[2], b[3] };
    memcpy(&f, le, 4);
    return f;
}

Detecting endianness on your machine

#include <stdint.h>
#include <stdio.h>
int main(void) {
    uint32_t x = 0x01020304;
    unsigned char *p = (unsigned char*)&x;
    printf("%s-endian\n", (p[0] == 0x04) ? "little" : "big");
    return 0;
}

JavaScript (Node)

const os = require('os');
console.log(os.endianness()); // 'LE' on most modern desktops

Python

import sys
print(sys.byteorder)  # 'little' on most machines

Network byte order vs host order

Network byte order = big-endian.
Host may be little-endian (Intel/ARM). Use conversion helpers.

C (sockets)

uint32_t host = 0x12345678;
uint32_t net  = htonl(host); // host->network (big-endian)
uint32_t back = ntohl(net);  // network->host

BLE/IoT example you can adapt

Let’s say a BLE sensor sends a 3-byte header followed by a payload with a 32-bit float in little-endian:

Header: FE <cmd> <len>
Payload (len bytes): first 4 bytes = float32 LE

JavaScript

function parseBlePacket(raw) {
  const hdr = new Uint8Array(raw.slice(0, 3));
  if (hdr[0] !== 0xFE) return null;
  const cmd = hdr[1], len = hdr[2];

  const payload = new Uint8Array(raw.slice(3, 3 + len));
  if (payload.length < 4) return null;

  const dv = new DataView(payload.buffer, payload.byteOffset, payload.byteLength);
  const value = dv.getFloat32(0, true); // little-endian
  return { cmd, value };
}

If the device were big-endian, you’d change true → false.

Common pitfalls (and how to avoid them)

Assuming host order = protocol order. Always read the spec; never guess.
Forgetting floats vs integers. Both need correct byte order; floats also need the right interpretation (IEEE-754).
Cross-language defaults. DataView requires you to specify endianness. struct in Python uses < (LE) and > (BE).
Partial reads. Streams may arrive in chunks; reassemble first, then decode.

FAQ

Is ARM big-endian or little-endian?

ARM is bi-endian in theory but almost all consumer devices run little-endian.

Why do networks use big-endian?

Early Internet standards chose big-endian for consistency across diverse hardware. It stuck.

Can compilers “fix” endianness automatically?

No. You must convert explicitly when crossing a boundary (file/protocol/socket).

Key takeaways

Endianness = byte order for multi-byte values.
Big-endian writes the “big end” first; little-endian writes the “little end” first.
Always convert at boundaries: files, networks, device protocols, and between different CPUs.

Endianness Explained: Big-Endian vs Little-Endian (With Clear Examples)