CBOR vs MessagePack
CBOR and MessagePack share the same design philosophy: a binary encoding of JSON-compatible data types (null, boolean, integer, float, string, array, map) that is more compact and faster to parse than JSON. CBOR (Concise Binary Object Representation, RFC 8949) is an IETF standard (STD 94, December 2020). It was designed with four goals: small code size for embedded systems, small message size, extensibility via semantic tags, and deterministic encoding (CTAP2 Canonical CBOR for signatures). CBOR's tag system allows encoding typed values (dates, URIs, bignum, MIME messages) without extending the core spec. MessagePack (msgpack.org spec) is a community-maintained specification without an RFC. It was created by Sadayuki Furuhashi at 2008 and has been adopted by Redis pub/sub, Fluentd log aggregation, and many gaming platforms. MessagePack's fixint encoding (integers 0–127 in one byte) makes it especially compact for typical application data. The practical differences are small. Both encode the same value types in similar byte counts. The main reasons to choose one over the other are ecosystem fit and standards requirements.
CBOR (RFC 8949) and MessagePack are both binary JSON-compatible serialization formats that are schema-free and self-describing. Both produce smaller payloads than equivalent JSON for typical structured data by eliminating string key repetition and encoding integers natively. CBOR is the IETF standard (STD 94) used in FIDO2/WebAuthn, IoT (CoAP), and privacy protocols. MessagePack is a community spec used in Redis, Fluentd, and gaming/messaging systems. Both are excellent – choose CBOR when standards compliance matters, MessagePack when you have an existing deployment or need Redis integration.
| Feature | CBOR | MessagePack |
|---|---|---|
| Specification | IETF RFC 8949 (December 2020) – STD 94 | Community spec (msgpack.org / github.com/msgpack) |
| Standards body | IETF – Internet Engineering Task Force | No RFC, community governance |
| Schema required | No – self-describing with type tags | No – self-describing with format bytes |
| Type system | 6 major types + semantic tag system for extension | 7 format families (fixint, float, str, bin, array, map, ext) |
| Integer encoding | Major type 0 (uint) + type 1 (nint). Up to 64-bit | fixint (1 byte 0–127), int8–int64, uint8–uint64 |
| Extension types | Tag system (RFC 8949 §3.4) – 65536 possible tags | ext type (-128 to 127) – timestamp ext type is -1 |
| Timestamps | Tag 1 (epoch seconds/fractional) | ext type -1 (Timestamp Extension) |
| Canonical encoding | CTAP2 Canonical CBOR defined for deterministic signing | No official canonical form |
| Payload size | Comparable to MessagePack for typical data | Comparable to CBOR; fixint is slightly more compact for 0–127 integers |
| Primary deployments | FIDO2/WebAuthn, CoAP (IoT), COSE, OHTTP, Apple iCloud | Redis pub/sub, Fluentd, NATS, MessagePack-RPC, gaming backends |
| Half-precision float | Yes – IEEE 754 half-precision (16-bit) | float32 and float64 only (no half-precision) |
| Undefined value | Simple value 23 (undefined) | No undefined value |
When to use CBOR
CBOR is the right choice when: you need IETF standards compliance (FIDO2/WebAuthn mandates CBOR, CoAP uses CBOR, COSE uses CBOR), when deterministic encoding matters for cryptographic signing (CTAP2 Canonical CBOR), when you need to represent typed values (dates, URIs, bignums) via the semantic tag system, or when your deployment will be reviewed for FIPS/standards compliance.
When to use MessagePack
MessagePack is the right choice when: you are integrating with Redis (Redis pub/sub commonly uses MessagePack), building on Fluentd or Fluent Bit (native MessagePack), working in gaming or messaging backends where MessagePack has existing ecosystem support, or migrating an existing JSON API to binary where MessagePack libraries are available and familiar to the team.
Common Mistakes
- Treating CBOR and MessagePack as interchangeable – they have different byte encodings and are not mutually parseable. A CBOR library cannot parse MessagePack and vice versa. Choose one per protocol and document the choice.
- Ignoring the CBOR tag system – CBOR's tags allow encoding domain-specific types (dates, UUIDs, IP addresses) in a self-describing way. Using raw string encoding for these types (as JSON does) wastes the main advantage of using CBOR.
- Not specifying deterministic encoding for CBOR when ordering matters – CBOR maps do not have guaranteed key ordering by default. For cryptographic applications (WebAuthn, COSE), always use CTAP2 Canonical CBOR which mandates map key ordering.
FAQ
Is CBOR a replacement for MessagePack?
CBOR was designed with lessons from MessagePack but is not a direct replacement. CBOR has an RFC and is used in standards-required contexts (FIDO2, CoAP, COSE). MessagePack has existing deployments in Redis and gaming. If you are starting fresh with no existing deployment, CBOR is preferable for its RFC backing and tag system.
Which is smaller: CBOR or MessagePack?
For typical application payloads (mixed strings, integers, arrays), the byte size difference is negligible (within 1–5%). MessagePack's fixint encoding (integers 0–127 in one byte) is slightly more compact for integer-heavy data. CBOR's half-precision float support gives it an edge for sensor data with limited precision.