# Endianness

**Endianness** (also called byte order) is the convention a computer architecture uses to arrange the bytes of a multi-byte value in memory. A byte holds only 8 bits, so numbers larger than 255 occupy several bytes, and the architecture must decide which byte sits at the lowest address: big-endian places the most significant byte first, little-endian places the least significant byte first.<sup>[1](https://developer.mozilla.org/en-US/docs/Glossary/Endianness)</sup><sup> • </sup><sup>[2](https://docs.oracle.com/en/operating-systems/oracle-linux/6/porting/ch03s04.html)</sup>

| Key fact | Detail |
|---|---|
| Definition | The order of bytes of a multi-byte value in memory; big-endian stores the most significant byte at the lowest address, little-endian the least significant.<sup>[2](https://docs.oracle.com/en/operating-systems/oracle-linux/6/porting/ch03s04.html)</sup> |
| Worked example | The 32-bit value 0x12345678 is stored as bytes 0x12, 0x34, 0x56, 0x78 in big-endian order and 0x78, 0x56, 0x34, 0x12 in little-endian order.<sup>[3](https://learn.microsoft.com/en-us/openspecs/sql_server_protocols/ms-rgdi/5a0940d9-818b-4eef-b6be-310ef1023e01)</sup> |
| Dominant convention | Little-endian is described as by far the most common ordering and is used on all Intel processors; Intel x86, AMD64, and Apple M1 are little-endian.<sup>[1](https://developer.mozilla.org/en-US/docs/Glossary/Endianness)</sup><sup> • </sup><sup>[4](https://docs.python.org/3/library/struct.html)</sup>  |
| Big-endian systems | IBM z and many legacy architectures are big-endian; Motorola processors have always been big-endian.<sup>[4](https://docs.python.org/3/library/struct.html)</sup><sup> • </sup><sup>[2](https://docs.oracle.com/en/operating-systems/oracle-linux/6/porting/ch03s04.html)</sup>  |
| Network byte order | Internet standards require big-endian transmission; RFC 791 specifies that the most significant octet of a multi-octet quantity is transmitted first.<sup>[1](https://developer.mozilla.org/en-US/docs/Glossary/Endianness)</sup><sup> • </sup><sup>[5](https://www.rfc-editor.org/rfc/rfc791.html)</sup>  |
| Conversion functions | POSIX provides htonl, htons, ntohl, and ntohs to convert 16- and 32-bit values between host and network byte order.<sup>[6](https://pubs.opengroup.org/onlinepubs/000095399/functions/htonl.html)</sup> |
| File-format markers | TIFF files declare their byte order in the first two bytes: "II" for little-endian, "MM" for big-endian.<sup>[7](https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf)</sup> |
| Bi-endian hardware | ARMv4 and ARMv5 support both big-endian and little-endian operation, and the RISC-V privileged architecture defines bi-endian operation.<sup>[8](https://documentation-service.arm.com/static/5f8daeb7f86e16515cdb8c4e)</sup><sup> • </sup><sup>[9](https://docs.riscv.org/reference/isa/v20250508/unpriv/intro.html)</sup>  |

## How byte order works

Memory is byte-addressable: each storage location has an index or address, and every byte stores an 8-bit number between 0x00 and 0xff. Storing a larger number therefore requires several consecutive bytes, and the architecture must choose which byte takes the first, lowest address.<sup>[1](https://developer.mozilla.org/en-US/docs/Glossary/Endianness)</sup>

In a little-endian machine, bytes are stored in order from least to most significant, so the least significant byte takes the lowest address. MDN compares this to a common European way of writing dates, such as 31 December 2050, with the smallest unit first. Big-endian is the opposite order, comparable to an ISO date such as 2050-12-31.<sup>[1](https://developer.mozilla.org/en-US/docs/Glossary/Endianness)</sup> Oracle's porting guide illustrates the same distinction with the value 0xFF342109 at addresses 0x1000 through 0x1003: a little-endian system stores 0x09 at 0x1000 and 0xFF at 0x1003, while a big-endian system stores 0xFF at 0x1000 and 0x09 at 0x1003.<sup>[2](https://docs.oracle.com/en/operating-systems/oracle-linux/6/porting/ch03s04.html)</sup>

The NIST glossary frames the same idea in terms of significance: big-endian places the most significant byte (or digit) first, little-endian places it last, and humans tend to represent numbers big-endian, writing 10 as ten rather than as one.<sup>[10](https://www.nist.gov/glossary-term/22791)</sup>

A third scheme exists. Mixed-endian, also called middle-endian, orders bytes neither purely from the big end nor from the little end; MDN gives the historic and very rare example of 0x12345678 stored as 0x34 0x12 0x78 0x56.<sup>[1](https://developer.mozilla.org/en-US/docs/Glossary/Endianness)</sup>

## Which architectures use which

Little-endian dominates current commercial processors. Intel x86, AMD64 (x86-64), and [Apple M1](https://www.edgepedia.org/apple-m1) are little-endian, and the RISC-V designers state that little-endian systems are currently dominant commercially, covering all x86 systems and iOS, Android, and Windows on ARM.<sup>[4](https://docs.python.org/3/library/struct.html)</sup><sup> • </sup><sup>[9](https://docs.riscv.org/reference/isa/v20250508/unpriv/intro.html)</sup>

Big-endian designs include IBM z and many legacy architectures, and Motorola processors have always been big-endian.<sup>[4](https://docs.python.org/3/library/struct.html)</sup><sup> • </sup><sup>[2](https://docs.oracle.com/en/operating-systems/oracle-linux/6/porting/ch03s04.html)</sup>  A SCO driver handbook adds the [Sun SPARC](https://www.edgepedia.org/sparc), IBM PowerPC, and Hewlett-Packard Precision Architecture systems, as well as SCSI devices and network protocols, to the big-endian list.<sup>[11](https://osr600doc.sco.com/en/HDK_concepts/ddT_endian.html)</sup> Older Macintosh computers built on 68000-series and PowerPC microprocessors formerly used big-endian.<sup>[1](https://developer.mozilla.org/en-US/docs/Glossary/Endianness)</sup>

The DEC PDP-11, a widely used 1970s minicomputer with 16-bit words and 8-bit bytes, was byte-addressable and little-endian.<sup>[12](https://www.teach.cs.toronto.edu/~ajr/258/notes/pdp11.html)</sup>

**Bi-endian architectures** let software choose. ARMv4 and ARMv5 support both big-endian and little-endian operation, with the distinction managed by changing the addresses of the bytes within a word.<sup>[8](https://documentation-service.arm.com/static/5f8daeb7f86e16515cdb8c4e)</sup> RISC-V base ISAs come in little-endian or big-endian memory versions, with the privileged architecture further defining bi-endian operation; the designers chose little-endian by default because of its commercial dominance and because they found little-endian memory systems more natural for hardware designers, while keeping big-endian variants for application areas such as IP networking and legacy code bases.<sup>[9](https://docs.riscv.org/reference/isa/v20250508/unpriv/intro.html)</sup>

## Why the order matters

The two orders carry different practical advantages. A Harvard Extension course slide set lists little-endian benefits: bits, bytes, halfwords, and words are all numbered from least to most significant; in extended-precision byte arithmetic, carry bits propagate from lower to greater significant bytes and also from lower to greater addresses; and a pipelined architecture may access memory in the order a pipeline requires. Big-endian benefits include faster comparison of words fully packed with bytes, and printing bytes in ascending address order yields the correct most-to-least significant order.<sup>[13](https://cscie92.dce.harvard.edu/spring2024/slides/Endianness.pdf)</sup>

Endianness becomes visible whenever data crosses a boundary between systems. The IBM Redbooks porting guide notes that byte-ordering issues are often encountered when migrating applications, device drivers, or data files between architectures, and that code intended for both platforms must be endian-neutral or use conditional compilation.<sup>[14](https://www.redbooks.ibm.com/redbooks/pdfs/sg246034.pdf)</sup> A SCO handbook makes the same point for driver code: as the code evolves, it must be modified and tested on both little-endian and big-endian systems.<sup>[11](https://osr600doc.sco.com/en/HDK_concepts/ddT_endian.html)</sup>

## Network byte order

Internet protocols fix a single convention. RFC 791, the [Internet Protocol](https://www.edgepedia.org/internet-protocol) specification, resolves transmission order to the octet level and states that when a multi-octet quantity is transmitted, the most significant octet is transmitted first.<sup>[5](https://www.rfc-editor.org/rfc/rfc791.html)</sup> This big-endian layout is called network byte order, a term defined in IETF RFC 1700, and it applies from the standard UNIX socket level up to standardized web binary data structures.<sup>[4](https://docs.python.org/3/library/struct.html)</sup><sup> • </sup><sup>[1](https://developer.mozilla.org/en-US/docs/Glossary/Endianness)</sup>

POSIX systems expose the conversion through four functions: htonl and htons convert 32- and 16-bit values from host to network byte order, and ntohl and ntohs convert in the other direction; 8-bit values stored in uint8_t objects need no conversion because both orders give the same representation.<sup>[6](https://pubs.opengroup.org/onlinepubs/000095399/functions/htonl.html)</sup><sup> • </sup><sup>[15](https://pubs.opengroup.org/onlinepubs/009696699/basedefs/xbd_chap04.html)</sup>

## Endianness in file formats

File formats handle the problem in two ways: fixing one order, or declaring the order in the file itself.

**Fixed-order formats.** The PNG specification requires all integers that require more than one byte to be in network byte order, with the most significant byte first (MSB LSB for two-byte integers, B3 B2 B1 B0 for four-byte integers).<sup>[16](https://libpng.org/pub/png/spec/1.2/PNG-DataRep.html)</sup>

**Self-declaring formats.** A TIFF file begins with an 8-byte header whose first two bytes give the byte order used within the file: "II" (hexadecimal 4949) selects little-endian order, least significant byte first for both 16-bit and 32-bit integers, and "MM" (4D4D) selects big-endian order, most significant byte first.<sup>[7](https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf)</sup> The corresponding magic numbers are 49 49 2A 00 for little-endian and 4D 4D 00 2A for big-endian files.<sup>[17](https://datatracker.ietf.org/doc/html/rfc3302)</sup> The TIFF specification requires a correct reader to handle both byte orders.<sup>[18](https://web.mit.edu/graphics/src/tiff-v3.5.5/html/libtiff.html)</sup>

## Handling byte order in code

Programming interfaces make the choice explicit. Python's struct module uses format-string prefixes: "<" for little-endian, ">" for big-endian, and "!" for network byte order, which is always big-endian as defined in RFC 1700. Packing the number 1023 as a signed short gives b'\x03\xff' in big-endian and b'\xff\x03' in little-endian. The module's documentation advises that when exchanging data beyond a single process, such as over a network or in storage, the programmer should specify the exact byte order rather than assume it matches the native order of a particular machine.<sup>[4](https://docs.python.org/3/library/struct.html)</sup>

The choice of endianness remains visible in new instruction set design. RISC-V stores instructions as a sequence of 16-bit little-endian parcels regardless of the memory system's endianness, decoupling the instruction encoding from memory byte order so that software can be endianness-agnostic even in binary form; the designers note that big-endian JIT compilers must swap byte order when storing to instruction memory as a consequence.<sup>[9](https://docs.riscv.org/reference/isa/v20250508/unpriv/intro.html)</sup>

## References

1. [Endianness, MDN Web Docs Glossary](https://developer.mozilla.org/en-US/docs/Glossary/Endianness)
2. [Byte Ordering, Oracle Linux 6 Porting Guide](https://docs.oracle.com/en/operating-systems/oracle-linux/6/porting/ch03s04.html)
3. [MS-RGDI: Byte Ordering, Microsoft Learn](https://learn.microsoft.com/en-us/openspecs/sql_server_protocols/ms-rgdi/5a0940d9-818b-4eef-b6be-310ef1023e01)
4. [struct, Interpret bytes as packed binary data, Python 3 documentation](https://docs.python.org/3/library/struct.html)
5. [RFC 791: Internet Protocol, RFC Editor](https://www.rfc-editor.org/rfc/rfc791.html)
6. [htonl, htons, ntohl, ntohs, POSIX specification](https://pubs.opengroup.org/onlinepubs/000095399/functions/htonl.html)
7. [TIFF 6.0 Specification, June 3, 1992](https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf)
8. [ARM Architecture Reference Manual, ARMv7-A and ARMv7-R edition](https://documentation-service.arm.com/static/5f8daeb7f86e16515cdb8c4e)
9. [RISC-V Unprivileged ISA, Introduction](https://docs.riscv.org/reference/isa/v20250508/unpriv/intro.html)
10. [Endian (Big Or Little), NIST OSAC Lexicon](https://www.nist.gov/glossary-term/22791)
11. [Endian issues for drivers, SCO HDK documentation](https://osr600doc.sco.com/en/HDK_concepts/ddT_endian.html)
12. [The PDP-11, University of Toronto course notes](https://www.teach.cs.toronto.edu/~ajr/258/notes/pdp11.html)
13. [Endianness, Harvard Extension course slides (Prof. James L. Frankel)](https://cscie92.dce.harvard.edu/spring2024/slides/Endianness.pdf)
14. [Byte ordering issues, IBM Redbooks SG24-6034](https://www.redbooks.ibm.com/redbooks/pdfs/sg246034.pdf)
15. [General Concepts, POSIX (network byte order)](https://pubs.opengroup.org/onlinepubs/009696699/basedefs/xbd_chap04.html)
16. [PNG Specification 1.2, Data Representation](https://libpng.org/pub/png/spec/1.2/PNG-DataRep.html)
17. [RFC 3302: image/tiff MIME Sub-type Registration](https://datatracker.ietf.org/doc/html/rfc3302)
18. [Using The TIFF Library, libtiff documentation](https://web.mit.edu/graphics/src/tiff-v3.5.5/html/libtiff.html)

---
*Topic: Encyclopedia › Technology and the built world › Computing and digital systems › Computer hardware › Processors & processor engineering › Instruction set architectures › ISA design concepts and classification*

*Initially written Sep 17, 2026 · Reviewed: Oct 15, 2026 · Edited: Oct 15, 2026 · Last review: Oct 15, 2026*

*Copyright 2026 EdgeChat AI, a subsidiary of Biostate AI.*

License: Edgepedia Community License 1.0, https://www.edgepedia.org/edgepedia/license