A binary cousin of JSON
CBOR takes the abstract structure that JSON popularised — maps, arrays, strings, numbers, booleans and null — and encodes it as bytes rather than characters. Each value begins with an initial byte whose top three bits name a major type and whose lower bits either carry a small value directly or announce how many length bytes follow. Because the format is self-describing, a decoder can walk an unknown document and reconstruct its shape without a separate schema, exactly as it could with JSON.
The differences are the interesting part. CBOR can store raw byte strings without base64 padding, encode floating-point numbers in half, single or double precision, and tag values to give them meaning — tag 0, for instance, marks a string as an RFC 3339 timestamp. This means a date, a cryptographic key or a small image survives a round trip without the inflation that text encodings impose.
Where it earns its keep
The format was written with constrained environments in mind: sensors, smart-home hardware and other devices where every byte of radio traffic and every cycle of CPU time matters. It is the payload format beneath COSE (CBOR Object Signing and Encryption) and therefore underpins WebAuthn and FIDO2, where browsers and authenticators exchange CBOR-encoded credentials during passkey registration. You will also find it in CoAP-based messaging and in configuration blobs that ship inside firmware.
CBOR deliberately keeps its encoders tiny, so a microcontroller can emit valid output from a few hundred bytes of code. That minimalism is a feature, not a limitation — it is the reason the format spread through standards bodies rather than through web front-ends.
Strengths
- Compact on the wire, with no quoting, escaping or base64 overhead for binary data.
- Self-describing, so documents can be decoded without a separate schema.
- An IETF Internet Standard (RFC 8949) with broad library support across languages.
- Native types for byte strings, dates and precise floats that JSON cannot express directly.
Limitations
- Not human-readable — you cannot inspect or hand-edit a file in a text editor.
- Multiple valid encodings of the same data can complicate signing unless canonical rules are applied.
- Tooling for casual users is thinner than for JSON, so debugging often needs a decoder.
- The flexibility of tags means two systems must still agree on which tags they understand.
When to use CBOR
Reach for CBOR when you need JSON’s flexible structure but in a small, fast binary form — typically on constrained devices, in security protocols, or as a wire format between services. For anything a person needs to read or edit by hand, plain JSON is the better choice.
CBOR FAQ
- What is a CBOR file?
- It is a file holding data encoded with Concise Binary Object Representation, a compact binary version of the JSON data model standardised in RFC 8949. It is meant for machines, so opening it in a text editor shows bytes rather than readable text.
- How do I read a CBOR file?
- Convert it to JSON, which renders the same structure as readable text. Morphr can do this in the browser without uploading the file, turning the binary into JSON you can inspect and edit, then back again if needed.
- Is CBOR better than JSON?
- Neither is strictly better; they suit different jobs. CBOR is smaller and faster for machines and handles binary and dates natively, while JSON wins whenever a human needs to read, edit or diff the content.