CBOR Viewer & Converter

Decode CBOR (Concise Binary Object Representation) data and convert to/from JSON.

Tested tool guide Tested browser tools Checked August 16, 2026

What CBOR Viewer & Converter does, with a checked example

CBOR stores structured values in a compact binary form, so its bytes are not readable as ordinary JSON. This viewer accepts CBOR data, exposes decoded maps, arrays, strings, numbers, booleans, and null values, and can encode JSON in the reverse direction. The common surprise is that CBOR includes values JSON cannot represent directly, such as byte strings, tags, and maps with non-string keys. A readable JSON result can therefore be an interpretation rather than a lossless replacement for the original CBOR.

Worked example

A concrete input and expected output from the current implementation.

Input

a26161016162820203

Expected output

{"a":1,"b":[2,3]}

Interpreted as hexadecimal CBOR, a2 begins a two-pair map. The remaining bytes encode the text keys "a" and "b", the integer 1, and a two-item array containing 2 and 3.

How the result is produced

Decoding CBOR

When input is supplied as hexadecimal, each pair of hex digits represents one byte. CBOR's leading bytes identify each value's major type and provide its value or length information. The viewer follows those boundaries through nested maps and arrays, then displays the resulting structure in a JSON-readable form.

Encoding JSON

In the reverse direction, valid JSON values are converted to corresponding CBOR values. JSON objects become maps with text-string keys, arrays retain their item order, and strings, booleans, null, and numbers use compatible CBOR types. Plain JSON has no syntax for requesting CBOR byte strings, semantic tags, or non-string map keys.

Good uses

Read a hexadecimal CBOR payload copied from an IoT device log without decoding each byte by hand.
Turn a small JSON fixture into CBOR for a protocol test that expects binary structured data.
Check whether a hand-authored CBOR example contains the intended nested maps, arrays, keys, and values.

Limits and checks

Hexadecimal input must contain complete bytes. An odd number of hex digits, a non-hex character, or a missing byte can make the CBOR item malformed or truncated.
Byte strings, tags, non-string map keys, and duplicate map keys do not have faithful ordinary JSON equivalents. Inspect how these values are represented before reusing the JSON.
Different CBOR byte sequences can represent equivalent data, including different integer widths and definite or indefinite lengths. Matching decoded values does not prove that two encodings are byte-for-byte identical or canonical.

Common questions

Is CBOR just compressed JSON?

No. CBOR is a binary data format with a data model that overlaps JSON but also includes additional types. Its compactness comes from binary type, value, and length encoding, not from applying a general compression scheme. A CBOR document may still contain repeated data that an external compressor could reduce.

Will converting CBOR to JSON and back reproduce the original bytes?

No, not necessarily. The decoded values may survive, but the original encoding choices need not. Map ordering, integer and floating-point widths, definite versus indefinite lengths, tags, byte strings, and values without direct JSON equivalents can all prevent a byte-identical round trip.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.