= Fixed-width length field
A \b[fixed-width length field] uses a fixed number of encoded bytes to state a payload length. The payload itself can vary in size. For an unsigned $k$-byte field in big-endian <endianness>, bytes $b_0,\ldots,b_{k-1}$ represent
$$
n=\sum_{i=0}^{k-1}b_i256^{k-1-i},\qquad
0\leq n\leq256^k-1.
$$
The format must additionally define the length unit, permitted range and whether headers count toward it. TLS uses unsigned, network-order integers and gives variable-length vectors a prefix wide enough for their declared maximum; its vector length counts bytes, not elements.<The Transport Layer Security Protocol Version 1.3 (RFC 8446)>[§3.3, numeric types and network byte order; §3.4, vector lengths and prefix width]{ref}
For an original two-byte <length-prefixed encoding>, prefix `02 01` means $2\cdot256+1=513$ payload bytes in big-endian order. The complete field then occupies $515$ bytes. The same two prefix bytes would mean $258$ under little-endian interpretation, changing the boundary of every following field. The byte order is therefore part of the <serialization>, not a display preference.
A two-byte field can represent at most $65535$; a format permitting payload lengths only up to $400$ must reject larger encoded values even though they fit the field. Conversely, a $300$-byte payload needs prefix `01 2c` under this convention. Truncating it to one byte would declare only $44$ bytes. A format change cannot be implemented by silently discarding high-order bits.
<Length-prefix validation before allocation> checks the declared range and available input before reserving space or consuming the payload. A complete decoder also specifies how truncation and trailing bytes are handled. Byte count and character count differ for encodings such as <UTF-8>. A length prefix supplies boundaries; a field's role or type may still need binding through <cryptographic domain separation>.
Back to article page
