CBOR Encoder / Decoder

What is CBOR?

CBOR (Concise Binary Object Representation, RFC 8949) is a binary data format built on the same data model as JSON — numbers, strings, arrays, maps, booleans, and null — but encoded as compact bytes instead of text. Every value is a short type header (major type + length) followed immediately by its content, so there's no punctuation, no quoting, and no whitespace to pad out the payload.

That compactness is why CBOR shows up wherever bandwidth or parsing cost matters: CoAP (the HTTP-like protocol for constrained IoT devices), COSE (signed/encrypted CBOR objects used in WebAuthn and FIDO2 passkeys), CWT (CBOR Web Tokens, JWT's binary sibling), Docker’s content-addressable storage, and countless embedded and low-power messaging protocols. If JSON is "human-readable data on the wire," CBOR is the same data model built for wires with a byte budget.

How to use it

1. Choose a Mode:
   • Encode JSON → CBOR — paste a JSON value (an object, array, string, number, boolean, or null) into the input box. The tool parses it and CBOR-encodes it, showing the result as Hex or Base64 (pick the format from the dropdown).
   • Decode CBOR → JSON — paste CBOR bytes as hex or Base64; the format is auto-detected. The tool decodes the bytes and shows the equivalent JSON value, pretty-printed.
2. Copy or download the result with the buttons on the output box.
3. Processing happens instantly as you type or switch modes — there's no separate "run" step.

How values map between JSON and CBOR

• Integers encode using CBOR's shortest form: values 0–23 fit in the single header byte; larger magnitudes use a 1/2/4/8-byte follow-on length, chosen automatically. Negative numbers use CBOR's dedicated negative-integer major type.
• Strings are UTF-8 text strings (CBOR major type 3).
• Arrays and objects map to CBOR arrays and maps (major types 4 and 5) — object keys are always encoded as text strings.
• true, false, null use CBOR's three-byte "simple value" encoding.
• Non-integer numbers (anything with a decimal point, or too large to be a safe integer) are encoded as 8-byte double-precision floats — this tool always uses double precision rather than CBOR's optional half/single-precision shortcuts, trading a few bytes of size for simplicity and lossless round-tripping.
• Decoding also understands CBOR concepts that don't exist in JSON — byte strings, tags, and "simple" values — by representing them as JSON-friendly placeholders (e.g. a byte string decodes to "h'a1b2c3'", a tag to {"$tag": N, "value": ...}) rather than failing.

FAQ

Why does encoding a plain number sometimes change size unpredictably? CBOR always picks the shortest valid header for an integer's magnitude — 10 is one byte, 1000 is three, 100000 is five. This isn't a bug; it's the point of the format.

Can I decode CBOR produced by another library? Yes — decoding handles arbitrary well-formed CBOR (any combination of major types, definite or indefinite length, tags), not just data this tool itself produced.

What happens with malformed or truncated input? Both modes report a clear inline error (invalid JSON, or a description of exactly what's wrong with the CBOR bytes — e.g. "Unexpected end of CBOR data") instead of failing silently.

Is my data uploaded anywhere? No — both encoding and decoding run entirely in your browser. Nothing you paste is sent to a server.