Binary Serialization Tools — MessagePack, CBOR, BSON & Protobuf

BSON (Binary JSON) is MongoDB's native format. It adds data types not available in JSON.

You get types like ObjectId, Date, BinData, Decimal128, Int64, Regex, and more.

Use BSON when you are working with MongoDB drivers or need these extra types. For general web APIs, JSON (or MessagePack/CBOR) is more interoperable.

Yes, typically 2-5x faster to parse and 20-50% smaller on the wire. Binary formats avoid text parsing overhead and use efficient integer and float encoding.

However, for small payloads (under 1KB), the difference is often negligible compared to network latency. Choose based on your throughput requirements and ecosystem support.

Yes. Protobuf is a contract-first format — the schema defines message structure, field numbers, and types. The encoder or decoder requires the compiled schema or a runtime parser like protobufjs.

BetterPass's Protobuf tool accepts .proto definitions directly in your browser for ad-hoc encoding and decoding.

From easiest to hardest in browsers: JSON > MessagePack ≈ CBOR > BSON > Protobuf.

JSON is native. MessagePack and CBOR have mature npm packages like @msgpack/msgpack and cbor2. BSON is mainly used via MongoDB drivers. Protobuf requires build-time compilation (protoc) or runtime parsing (protobufjs), which adds complexity.

Browser memory limits apply — typically 2-4GB. For payloads over 50MB, you will notice performance degrade.

These tools are designed for API debugging, config inspection, and development workflows — not ETL pipelines. For large-scale conversion, use native CLI tools like jq, msgpack-cli, cbor-cli, or protoc.

Protobuf (Protocol Buffers) is a serialization format — it defines how structured data is encoded into compact binary using a .proto schema.

gRPC is an RPC (Remote Procedure Call) framework that uses Protobuf as its default serialization layer, combined with HTTP/2 transport, streaming, and code generation for service stubs.

Think of Protobuf as the data format (like JSON) and gRPC as the communication protocol (like REST). You can use Protobuf without gRPC (for message queues, file storage), and you can use gRPC with other serialization formats (though Protobuf is the standard).

For typical JSON-like data, MessagePack is slightly faster to encode and decode in JavaScript. Its simpler type system means fewer branching paths. CBOR's semantic tag system and support for indefinite-length encoding adds parsing complexity.

However, CBOR excels with binary data, big integers, and datetime values — all handled natively without custom extension types.

MessagePack uses single-byte prefixes for common types, while CBOR uses a major/minor type system. For most web API workloads, the performance difference is under 10%.

Choose MessagePack for simplicity and JSON-like data. Choose CBOR when you need RFC-standard extensibility, IoT compliance, or built-in support for dates and binary.

The BSON specification has evolved across MongoDB versions. MongoDB 3.x uses BSON with limited Decimal128 support. 4.x added improved Decimal128 and extended JSON v2. 5.x+ requires BSON compliance with additional binary subtype definitions.

Key compatibility considerations:

• ObjectId binary format is consistent across all versions
• Date is always 64-bit UTC milliseconds
• BinData subtype 0 (generic) and 5 (UUID) are supported everywhere
• Decimal128 requires MongoDB 3.4+ with full support in 4.0+
• Int64 may be truncated to 53-bit integer in JavaScript if not handled via BigInt

For cross-version compatibility, avoid Decimal128 for pre-3.4 systems and use BinData subtype 4 (UUID) instead of subtype 3 (old UUID) for new applications.