[a] Like JSON it allows the transmission of data objects that contain name–value pairs, but in a more concise manner.

This increases processing and transfer speeds at the cost of human readability.

[4] CBOR was inspired by MessagePack, which was developed and promoted by Sadayuki Furuhashi.

Each data item consists of a header byte containing a 3-bit type and 5-bit short count.

For types 4 (array) and 5 (map), the count is the number of items (pairs) in the payload.

Extended counts, and all multi-byte values, are encoded in network (big-endian) byte order.

Because nested items may also use the indefinite encoding, the parser must pair the break markers with the corresponding indefinite-length header bytes.

Type 5 is similar but encodes a map (also called a dictionary, or associative array) of key/value pairs.

RFC 8746 defines tags 64–87 to encode homogeneous arrays of fixed-size integer or floating-point values as byte strings.

This is a semantic no-op, but allows the corresponding tag bytes d9 d9 f7 to be prepended to a CBOR file without affecting its meaning.

These bytes may be used as a "magic number" to distinguish the beginning of CBOR data.

It follows the same encoding-size rules as the other atomic types (0, 1, and 6), but the count field is interpreted differently.

This is related to, but different from, the use with other major types where a short count of 31 begins an indefinite length encoding.

IANA has created the CBOR tags registry, located at https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml .