The short answer

Paste a valid JSON value to measure its actual UTF-8 byte length and see broad planning ranges for CBOR and MessagePack. The measurement is exact for the JSON text you entered. The compact-format figures are deliberately ranges, because an honest encoded size depends on field names, value types, schema choices, library behavior, and whether equivalent information is represented.

The tool does not estimate Protobuf. Protobuf size cannot be inferred responsibly from JSON text without a message schema, field numbers, wire types, presence rules, and the values passed to a real encoder.

Input

Enter the exact JSON representation you expect a device or service to produce, including property names, string values, numbers, arrays, and whitespace. The sample is:

{"deviceId":"pump-042","temperature":21.6,"running":true}

The parser accepts any valid JSON value, although an object is the most common IoT payload. Whitespace counts toward JSON bytes because it is part of the transmitted text. Non-ASCII characters may occupy more than one UTF-8 byte, so JavaScript character count and wire byte count are not interchangeable.

Do not paste production secrets, personal data, access tokens, or customer payloads. A representative synthetic sample is enough for a planning comparison.

Method and planning ranges

JSON size is measured with the browser’s UTF-8 TextEncoder:

UTF-8 byte length of the exact input string

If parsing fails, the tool reports the measured byte length but stops the format comparison until the JSON syntax is fixed.

For valid JSON, the tool displays these explicit heuristic ranges:

  • CBOR: 45% to 75% of the entered JSON byte length.
  • MessagePack: 50% to 80% of the entered JSON byte length.

The bounds are rounded upward to whole bytes. They are not format guarantees, benchmark results, or claims that one encoding always beats another. Short keys, repeated structures, numeric types, schema-informed encodings, string tables, and compression can move a real result substantially. Run the same logical message through the actual production library to replace the range.

Worked example

The included pump payload is 57 UTF-8 bytes. The tool reports a CBOR planning range of 26–43 bytes and a MessagePack planning range of 29–46 bytes. It declines to invent a Protobuf result.

At one message per minute, saving 20 bytes removes 28,800 payload bytes per device per day. Across a large fleet that can matter, but it may still be small beside topic names, MQTT headers, TLS and TCP/IP framing, radio headers, acknowledgements, keepalives, retransmissions, or billing increments. Conversely, changing a message from every second to every minute reduces traffic far more than shaving a few bytes from the encoding. Optimize the system boundary, not the sample in isolation.

Limitations and trade-offs

The calculator does not run a CBOR or MessagePack encoder. It does not account for canonical encoding, tags, extension types, integer widths, floating-point choices, schemas, compression dictionaries, batching, topic length, MQTT properties, transport framing, encryption, fragmentation, or retransmission. It also does not compare encoding and decoding CPU time, RAM, firmware size, observability, browser support, or the cost of debugging binary traffic.

Equivalent semantics matter. Comparing JSON with readable field names against a binary payload that removes fields, changes precision, or relies on out-of-band schema state is not an encoding-only comparison. Include schema distribution and evolution in the decision.

Privacy and exports

The JSON input is parsed and measured only in this browser. It is intentionally excluded from the URL, copied parameters, and export parameter block so payload content does not leak into browser history, shared links, or referrer data. The generated result contains only byte counts and explanatory ranges.

Copy creates a Markdown result. JSON, CSV, and Markdown files are assembled locally and downloaded by the browser. No payload or result is uploaded to IoT 01.

FAQ

Why does indentation make the payload larger?

Spaces and line breaks are bytes in JSON. Minify the exact payload before comparing wire size, while preserving readable fixtures for tests and support.

Which binary format should I choose?

Size alone is insufficient. Compare schema evolution, implementation availability, CPU and memory cost, debuggability, interoperability, and actual encoded bytes for representative messages.

Can I use the midpoint as a capacity number?

Only for an early scenario with the range clearly preserved. Procurement and protocol decisions should use output from the real encoder and full packet captures.

Read Designing device message contracts to decide which fields belong in a message, how they evolve, and where encoding fits within the wider contract.