What is RFC 8949 diagnostic notation?

RFC 8949 §8 defines a human-readable notation for CBOR data items that preserves details JSON cannot express: Byte strings render as h'48656C6C6F' instead of a quoted string. Tags wrap their content, e.g. 1(1700000000) for an epoch date or 32("https://example.com") for a URI. Tag 24 (embedded CBOR) renders as <<1, 2, 3>> with the inner item decoded. Floats are distinguished from integers, e.g. 2.0 versus 2 . Switch the decode output to Diagnostic to see exactly what the bytes mean, including value types that JSON hides.

How does the Hex Dump Diff work?

Open the Hex Dump Diff tab, paste a JSON document (or drop a file), and hit Compare bytes . The tool encodes it and renders two classic hex dumps: JSON text bytes — the pretty-printed document as UTF-8, every quote, brace, comma, and space visible. CBOR bytes — the binary encoding, annotated with the root type read from the payload, e.g. map · 2 pairs or tag 1 · epoch-based date/time . Both columns share a byte offset ruler, and a summary row reports both sizes plus the percentage saved.

How are common CBOR tags rendered?

The decoder understands the tags defined by RFC 8949 and common registrations: Tag 0/1 — date/time strings and epoch-based dates render as ISO strings, e.g. {"$date":"2023-11-14T22:13:20.000Z"} . Tag 2/3 — positive and negative bignums render as {"$bigint":"18446744073709551616"} so huge integers keep full precision. Tag 24 — embedded CBOR data items render as {"$cbor":{…}} with the inner item decoded. Tag 32/36 — URIs and MIME messages render as {"$uri"} and {"$mime"} . Byte strings render as {"$bytes":"deadbeef"} and unknown tags as {"$tag":…} so nothing is silently dropped.

When should I prefer CBOR over JSON or MessagePack?

There is no universal winner — it depends on what your data and ecosystem need: Standards-driven environments — WebAuthn, COSE, CoAP, and other RFC-governed protocols specify CBOR as their encoding, so use it there rather than introducing a competing format. Richer types — dates, bignums, byte strings, and embedded data have native tag support in CBOR, giving you unambiguous semantics without custom conventions. Interop over speed — CBOR prioritizes a strict, well-specified binary format; if raw parsing speed is the only goal and your data is plain JSON-shaped, MessagePack is often lighter and faster. Tiny text payloads — for occasional small messages, JSON remains the simplest choice since every mainstream language parses it with zero setup. In short: pick CBOR for standards compliance or richer types, MessagePack for maximum speed on simple data, and JSON when human readability or ecosystem tooling matters more than byte size.

Is the CBOR tool free and private?

Yes, on both counts. Encoding, decoding, diagnostic notation, and hex dumps all run client-side with cbor-x — your data never leaves your device, is never transmitted, and is never cached on a server. No account or API key required.

CBOR Encode/Decode Online

Convert JSON to CBOR and back, read RFC 8949 diagnostic notation, render semantic tags, and diff the raw bytes side by side — all in your browser.

Binary output

Result

JSON input

What is CBOR Encode/Decode Online?

CBOR (Concise Binary Object Representation, RFC 8949) is the compact binary serialization format behind WebAuthn passkeys, COSE messages, and IoT protocols like CoAP. It encodes the same structures as JSON into a fraction of the bytes while adding native support for byte strings, semantic tags, and bignums. This toolbox turns CBOR into something you can actually inspect: it converts JSON to CBOR (hex or base64), decodes binary back into readable JSON or RFC 8949 diagnostic notation, renders common semantic tags readably, and diffs the JSON vs CBOR byte streams side by side.

Convert — encode JSON to CBOR (hex or base64) or decode it back, with file upload in both directions.

Diagnostic notation — view decoded CBOR as RFC 8949 §8 diagnostic notation: h'...' byte strings, <<...>> embedded data, and 1(...) tags.

Common tag rendering — tag 0/1 dates, tag 2/3 bignums, tag 24 embedded CBOR, tag 32 URIs, tag 36 MIME.

Hex Dump Diff — compare the JSON text bytes against the CBOR bytes byte-for-byte with offset rulers.

100% client-side — everything runs locally with cbor-x, the same codec used in the snippets.

Zero-Server Tool Data Guarantee

All encoding and decoding happens locally in your browser. Your data is never sent to any server.

How to Use

Choose Your Mode

Select 'Encode' to turn JSON data into CBOR binary, or 'Decode' to convert CBOR bytes back to readable output. Drop a file instead of pasting — decode mode reads the raw bytes.

Set Encoding Type

Pick either 'Hex' or 'Base64' as the text representation for your binary CBOR data.

Pick an Output View (decode)

Choose 'JSON' for a plain decoded object or 'Diagnostic' for RFC 8949 §8 diagnostic notation with h'...' byte strings, <<...>> embedded data, and n(...) tags.

Inspect Semantic Tags

Dates (tag 0/1), bignums (tag 2/3), and embedded CBOR (tag 24) render readably in both views, so nothing is silently dropped.

Diff the Bytes

Open the Hex Dump Diff tab to see JSON and its CBOR encoding side by side with offset rulers and top-level type annotations.

Common Use Cases

WebAuthn / FIDO2 Debugging

Decode CBOR-encoded authenticator data from WebAuthn registration and authentication ceremonies.

IoT Data Serialization

Encode sensor readings and device state into compact CBOR for transmission over constrained networks.

COSE Message Inspection

Decode the payload of COSE-signed or encrypted messages used in firmware update and device authentication protocols.

Round-Trip Testing

Verify encode → decode round-trips, read diagnostic notation, and inspect tag-encoded values during schema migrations.

Implementation Examples

JavaScriptJavaScript (cbor-x)

import { encode, decode } from 'cbor-x';

const toHex = (bytes) => [...bytes].map((b) => b.toString(16).padStart(2, "0")).join("");

// Round-trip test: JSON -> CBOR bytes -> JSON
const doc = { id: 42, name: "sensor-7", active: true };
const bytes = encode(doc);
console.log(toHex(bytes)); // b90003626964182a646e616d656873656e736f722d3766616374697665f5

const decoded = decode(bytes);
console.log(decoded); // { id: 42, name: 'sensor-7', active: true }
console.log(JSON.stringify(decoded) === JSON.stringify(doc)); // true

// Big integers keep full precision through the tag-2 bignum
const huge = decode(encode(18446744073709551616n));
console.log(typeof huge, huge); // bigint 18446744073709551616

CBOR vs JSON vs MessagePack

Feature	CBOR	JSON	MessagePack
RFC	RFC 8949	RFC 8259	No formal RFC
Self-describing	Yes (type + value)	No (text only)	Partially
Semantic tags	Yes (tag system)	No	Extension types
Size	Very compact	Verbose	Compact
Schema required?	No	No	No
Primary use	IoT, WebAuthn, CoAP	APIs, config	High-perf APIs
Implementation	Moderate	Trivial	Simple

Production Best Practices & Security

Use CBOR for constrained devices — its compactness makes it ideal for IoT, sensors, and low-bandwidth networks. Why:CBOR uses variable-length integer encoding and minimal type prefixes, producing significantly smaller payloads than JSON. This saves precious bandwidth and energy on battery-powered or low-bandwidth IoT devices.

Understand the type system — CBOR maps JSON types differently (e.g., integers vs floats); be aware of automatic type selection. Why:CBOR distinguishes between positive integers, negative integers, and floating-point values at the binary level. A JSON number like 42 may be encoded as an integer, while 42.0 becomes a float, causing unexpected behavior if your decoder assumes JSON-like type rules.

Use semantic tags — leverage CBOR's tag system to add meaning to data (e.g., tag 1 for epoch dates, tag 24 for embedded CBOR). Why:Without semantic tags, a CBOR parser has no way to know that a string is a date or that bytes represent a cryptographic key. Tags add self-describing metadata that enables correct interpretation across different systems and implementations.

Validate input carefully — malformed CBOR can cause parser errors; always validate before processing. Why:Maliciously crafted CBOR can contain deeply nested structures or extremely large lengths that cause stack overflows or excessive memory allocation. Input validation prevents denial-of-service attacks against your parser.

Use hex for debugging — CBOR's binary format is hard to read raw; hex representation helps with analysis. Why:Raw CBOR bytes are not human-readable. Hex encoding preserves the exact byte sequence while making type codes, lengths, and values visible for manual inspection and debugging.

Consider COSE for security — if you need to sign or encrypt CBOR data, use the COSE standard built on top of CBOR. Why:COSE (RFC 9052) defines standardized ways to sign, encrypt, and authenticate CBOR data. Rolling your own CBOR security scheme risks subtle implementation vulnerabilities that COSE has already addressed through extensive peer review.

Frequently Asked Questions

CBOR (Concise Binary Object Representation) is a binary serialization format defined in RFC 8949 and inspired by JSON, designed to pack data into the smallest possible footprint. Think of it as JSON's compact, binary sibling — it represents the same kind of key-value structures and arrays, but encodes them using a fraction of the bytes.

CBOR is the format behind WebAuthn (passkey authentication), COSE (CBOR Object Signing and Encryption), and many IoT protocols where every byte counts on constrained devices.

JSON is human-readable text — a string like "hello" takes 7 bytes with quotes. CBOR encodes the same string in just 6 bytes using a binary prefix, and numbers, booleans, and null values are even more compact.

Beyond size, CBOR supports data types JSON cannot represent natively: byte strings, unsigned bignums, tagged values (like dates or URLs), and undefined.

The tradeoff is that CBOR is not human-readable — you need a tool like this one to decode it back into something you can inspect. For API debugging, config files, or anything where readability matters, stick with JSON. For protocols, storage, or transport where size and type richness matter, CBOR is the better choice.

Both are schemaless binary JSON alternatives, but they differ in design philosophy.

MessagePack prioritizes simplicity and speed — its single-byte prefixes for common types make it fast to parse and widely used in high-performance APIs.

CBOR prioritizes extensibility and standards compliance — its major/minor type system and semantic tags support dates, big integers, and custom types natively without vendor extensions.

CBOR is the standard for IoT (CoAP, COSE) and WebAuthn. MessagePack dominates real-time APIs, caching, and internal service communication. Compare them side by side with our MessagePack tool.

Both are binary serialization formats for JSON-like data, but they target different niches.

BSON is MongoDB's binary JSON — it exists to serve MongoDB's database engine, adding database-native types like ObjectId, Date, BinData, Decimal128, and Int64. It prioritizes traversal speed over compactness, so for the same data it is usually about as large as JSON.

CBOR is the IETF standard (RFC 8949) designed to be compact and extensible. It encodes the same data into roughly half the bytes of JSON and adds semantic tags for datetimes, UUIDs, and crypto objects — with no database dependency.

Choose BSON when you are working with MongoDB, CosmosDB, or DocumentDB. Choose CBOR for WebAuthn, COSE, IoT, or any standards-based protocol where wire size matters.

Paste hex-encoded CBOR data into the input field, switch to decode mode, and pick JSON or Diagnostic output. The tool parses the binary format and handles all CBOR types including integers, strings, arrays, maps, byte strings, and semantic tags.

If your CBOR data comes from a WebAuthn or COSE response, the tool structures the output for easy inspection. Click the copy button to copy the decoded result.

RFC 8949 §8 defines a human-readable notation for CBOR data items that preserves details JSON cannot express:

Byte strings render as h'48656C6C6F' instead of a quoted string.
Tags wrap their content, e.g. 1(1700000000) for an epoch date or 32("https://example.com") for a URI.
Tag 24 (embedded CBOR) renders as <<1, 2, 3>> with the inner item decoded.
Floats are distinguished from integers, e.g. 2.0 versus 2.

Switch the decode output to Diagnostic to see exactly what the bytes mean, including value types that JSON hides.

Open the Hex Dump Diff tab, paste a JSON document (or drop a file), and hit Compare bytes. The tool encodes it and renders two classic hex dumps:

JSON text bytes — the pretty-printed document as UTF-8, every quote, brace, comma, and space visible.
CBOR bytes — the binary encoding, annotated with the root type read from the payload, e.g. map · 2 pairs or tag 1 · epoch-based date/time.

Both columns share a byte offset ruler, and a summary row reports both sizes plus the percentage saved.

The decoder understands the tags defined by RFC 8949 and common registrations:

Tag 0/1 — date/time strings and epoch-based dates render as ISO strings, e.g. {"$date":"2023-11-14T22:13:20.000Z"}.
Tag 2/3 — positive and negative bignums render as {"$bigint":"18446744073709551616"} so huge integers keep full precision.
Tag 24 — embedded CBOR data items render as {"$cbor":{…}} with the inner item decoded.
Tag 32/36 — URIs and MIME messages render as {"$uri"} and {"$mime"}.

Byte strings render as {"$bytes":"deadbeef"} and unknown tags as {"$tag":…} so nothing is silently dropped.

There is no universal winner — it depends on what your data and ecosystem need:

Standards-driven environments — WebAuthn, COSE, CoAP, and other RFC-governed protocols specify CBOR as their encoding, so use it there rather than introducing a competing format.
Richer types — dates, bignums, byte strings, and embedded data have native tag support in CBOR, giving you unambiguous semantics without custom conventions.
Interop over speed — CBOR prioritizes a strict, well-specified binary format; if raw parsing speed is the only goal and your data is plain JSON-shaped, MessagePack is often lighter and faster.
Tiny text payloads — for occasional small messages, JSON remains the simplest choice since every mainstream language parses it with zero setup.

In short: pick CBOR for standards compliance or richer types, MessagePack for maximum speed on simple data, and JSON when human readability or ecosystem tooling matters more than byte size.