CBOR Encode Online — JSON to CBOR Bytes (RFC 8949)

Convert JSON to CBOR binary in your browser. RFC 8949-compatible output as base64 or hex, with live size comparison vs the equivalent JSON. 100% client-side — no upload, no account, no rate limits.

JSON Input

CBOR Output (base64)

Click Encode to convert JSON to CBOR base64 bytes.

Binary Serialization vs JSON

CBOR (Concise Binary Object Representation) is the IETF's answer to binary serialization — RFC 8949, the format that sits underneath COSE, CWT, and WebAuthn/FIDO2. It uses a 3-bit major type plus a length argument to encode the same shapes JSON does (null, bool, ints, floats, strings, arrays, maps), but in a fraction of the bytes. CBOR is the right pick whenever your protocol cites an RFC.

Like MessagePack, CBOR shines where machines talk to machines and bandwidth or parse cost matters: constrained IoT devices on LoRaWAN/Thread/Zigbee, remote attestation tokens, COSE-signed payloads, post-quantum credential blobs, and any place an IETF working group needed a self-describing wire format that wasn't XML or JSON. The encoder below is a pure-browser RFC 8949 implementation — paste JSON and inspect exactly how CBOR shrinks it.

How to encode JSON to CBOR — 4 steps

Paste JSON. Drop any valid JSON document into the input panel. Load Sample tries a representative IoT telemetry payload.
Choose output format. Base64 is compact (33% overhead) and transport-friendly; hex doubles the size but is easier to read byte-by-byte during debugging.
Click Encode. The encoder walks the JSON tree, emits the CBOR major type tags (0/uint, 3/string, 4/array, 5/map, 7/simple), and produces the binary buffer.
Inspect and copy. Compare the CBOR byte count to the JSON byte count — typical JSON-shaped data shrinks 30–50% — then copy the encoded payload.

Sample input and output

The same telemetry document encoded with CBOR. Notice the 0xa3 map header (major type 5, length 3) and the 0x18 0x2a two-byte uint encoding 42.

# JSON input
{"id":42,"name":"Atlas","online":true}

# CBOR hex output (~22 bytes)
a3 62 69 64 18 2a 64 6e 61 6d 65 65 41 74 6c 61
73 66 6f 6e 6c 69 6e 65 f5

# Tag breakdown
a3                    map, 3 entries
62 69 64              string(2) "id"
18 2a                 uint8 42
64 6e 61 6d 65        string(4) "name"
65 41 74 6c 61 73     string(5) "Atlas"
66 6f 6e 6c 69 6e 65  string(6) "online"
f5                    true

Compact Payloads

CBOR shrinks JSON-shaped data by 30–50% in typical workloads — integers, booleans, and short strings encode as 1–5 bytes per value.

IETF Standard

RFC 8949 is the IETF blessed binary format. It is the wire encoding underneath COSE, CWT, EAT, OSCORE, and WebAuthn attestation.

Browser-Only

The encoder is plain JavaScript inside your tab. JSON containing personal data, credentials, or attestation payloads never reaches our servers.

Common use cases

check_circleIoT telemetry over constrained networks (Thread, LoRaWAN, Zigbee, BLE, MQTT-SN)
check_circleCOSE-signed payloads (RFC 9052) and CWT tokens (RFC 8392) — both use CBOR as the underlying encoding
check_circleWebAuthn / FIDO2 attestation statements where CBOR is the mandated transport
check_circleCache values when the producing or consuming side is in the IETF / embedded ecosystem
check_circlePost-quantum credential blobs and SUIT firmware update manifests
check_circleService-to-service queues handling millions of events per second
check_circleEAT (Entity Attestation Token) and OSCORE (CoAP security) payloads
check_circleBlockchain transaction encodings where a self-describing binary format is preferred over RLP

JSON vs MessagePack vs CBOR vs Protobuf vs BSON

Format	Schema	Size vs JSON	Self-describing	Best for
JSON	None	100% (baseline)	Yes	Public APIs, configs, logs
MessagePack	None	~50–80%	Yes	IoT, caches, mobile APIs
CBOR (RFC 8949)	None	~50–80%	Yes	COSE/CWT, IETF protocols
Protobuf	Required (.proto)	~20–50%	No	gRPC, internal microservices
BSON	None	~110% (often larger)	Yes	MongoDB storage

Round-trip your data

Encode JSON to CBOR, then decode back to verify lossless round-trip — or compare against the MessagePack pair.

CBOR Decode MessagePack Encode MessagePack Decode

Frequently Asked Questions

What is CBOR?

CBOR (Concise Binary Object Representation) is the IETF-standard binary serialization format defined in RFC 8949. It is closely related to MessagePack — same JSON-equivalent data model, similar wire footprint — but standardised through the IETF process and used as the encoding underneath COSE (RFC 9052), CWT (RFC 8392), and the WebAuthn / FIDO2 attestation format. If your protocol cites an RFC, CBOR is usually the right choice.

CBOR vs MessagePack — which should I pick?

They are wire-compatible cousins, not interchangeable. Pick CBOR when interoperating with anything in the IETF stack (COSE, CWT, WebAuthn/FIDO2, OSCORE, EAT, SUIT manifests). Pick MessagePack when your stack is application-level and you want a slightly larger ecosystem of dynamic-language libraries, especially Python and Ruby. Both shrink JSON by similar amounts (~50%); the choice is ecosystem fit, not raw bytes.

Why is the output base64 or hex?

CBOR is raw bytes, so to display or paste it you need a text encoding. Base64 packs 3 bytes into 4 ASCII characters (33% overhead) and is the standard transport. Hex doubles size (2 chars per byte) but is easier to read by hand for debugging. Toggle the format above the output panel.

How does this encoder handle floats?

For simplicity, non-integer numbers are always encoded as float64 (major type 7, additional info 27, tag 0xfb). The CBOR spec also defines float16 (0xf9) and float32 (0xfa); the decoder counterpart reads all three. If you need bit-exact float32 output for COSE interop, the spec allows you to downcast values whose Math.fround() equals the original.

What about negative integers?

Major type 1 stores -(N+1), so -1 becomes argument 0, -100 becomes 99, -1000 becomes 999. The encoder handles this transformation automatically — you pass a normal JS number and the right tag and value go on the wire. The decoder applies the inverse at parse time.

Does this encoder produce canonical / deterministic CBOR?

It uses preferred serialization for argument widths (the smallest length encoding that fits) and float64 for non-integers, which matches most of the Section 4.2 deterministic profile of RFC 8949. Strict canonical encoding additionally requires sorting map keys by their CBOR-encoded form; this encoder preserves JSON key insertion order. For COSE_Sign1 deterministic encoding, run the output through a normalizing canonicaliser.

Are CBOR tags (date, bignum, etc.) supported?

Not by the encoder — the input is JSON, which has no native date or bignum types, so there is nothing for the encoder to tag. The decoder counterpart understands the structural majors (0–5, 7) and ignores tag wrappers transparently. For RFC 8949 tag 0/1 (datetimes), tag 2/3 (bignums), or RFC 8746 typed arrays, encode in code with cbor-x or cbor.js.

Is the data uploaded?

No. The encoder is plain JavaScript running in your tab. Open DevTools → Network and click Encode — there are zero outbound requests. JSON containing personal data, credentials, or attestation payloads never reaches our servers.