How is BSON different from JSON?

BSON differs from JSON in three key ways. It is binary — data is encoded in type-length-value format, making it faster to scan and parse. It supports richer data types including ObjectId , Date , BinData , Decimal128 , and Int64 , which JSON cannot represent natively. BSON is slightly larger than JSON on average (due to length prefixes and type markers) but optimized for traversal speed rather than size. JSON is human-readable and universally supported. BSON is machine-optimized and primarily used in the MongoDB ecosystem.

What is Extended JSON and how does the tool use it?

MongoDB's Extended JSON is the JSON-based notation that represents BSON types plain JSON cannot express: ObjectId → {"$oid":"507f1f77bcf86cd799439011"} Date → {"$date":"2023-11-14T22:13:20.000Z"} Binary → {"$binary":{"base64":"AQID","subType":"00"}} Decimal128 → {"$numberDecimal":"123.456"} Int32 / Int64 → {"$numberInt":"42"} / {"$numberLong":"9007199254740993"} Paste any of these forms into the encoder and the tool maps them to the real BSON types; decode renders BSON back into the same Extended JSON notation, either relaxed or canonical.

How do I decode BSON?

Paste hex- or base64-encoded BSON data into the input field (or drop a .bson file) and switch to decode . The tool parses the binary format and displays the result as Extended JSON. It correctly handles all MongoDB-specific types: ObjectId — displayed as {"$oid"} with a 24-character hex string Date — shown as ISO 8601 BinData — base64 with subtype Decimal128 , Int32 , Int64 , and RegExp Output is relaxed Extended JSON by default; tick Canonical to spell out every number type explicitly. If your BSON comes from a MongoDB export, the tool structures the output for easy inspection.

How do I use the ObjectId generator?

In Encode mode, place the cursor where you want the identifier and click ObjectId . The tool inserts a fresh {"$oid":"…"} (24 hex characters from 12 random bytes). If the input is empty it seeds a starter document: {"_id":{"$oid":"…"}} . Generated ObjectIds include a 4-byte timestamp prefix, but they are random — never treat them as monotonic sequence numbers.

How does the Hex Dump Diff work?

Paste a JSON document (or drop a file) and hit Compare bytes . The tool parses it as Extended JSON, encodes it to BSON, and renders two classic hex dumps: JSON text bytes — the canonical Extended JSON document as UTF-8, every {"$oid"} , quote, brace, and comma visible. BSON bytes — the binary encoding, annotated with the root document's field count, e.g. document · 3 fields . Both columns share a byte offset ruler, and a summary row reports both sizes plus the percentage difference.

Is the BSON tool free and private?

Yes, on both counts. Encoding, decoding, Extended JSON conversion, ObjectId generation, and hex dumps all run client-side with MongoDB's official bson library — no MongoDB connection is required, your data never leaves your device, and it is never transmitted or cached on a server. No account or API key required.

BSON Encode/Decode Online

Convert between Extended JSON and BSON, work with MongoDB types (ObjectId, Date, Binary, Decimal128), generate fresh ObjectIds, and diff the raw bytes side by side — all in your browser.

Binary output

Result

JSON input (Extended JSON supported)

What is BSON Encode/Decode Online?

BSON (Binary JSON) is the binary serialization format MongoDB uses to store documents and move data across its wire protocol. It extends JSON with types like ObjectId, Date, and Int64 that plain text cannot represent, and is designed for efficient storage and scanning. This toolbox turns BSON into something you can actually inspect: it converts Extended JSON — including ObjectId, Date, Binary, Decimal128, and Int64 values — into BSON bytes (hex or base64), decodes BSON back into readable relaxed or canonical Extended JSON, generates fresh ObjectIds for test documents, and diffs both byte streams as side-by-side hex dumps with offset rulers and top-level type annotations.

Binary format — unlike JSON's text-based format, BSON encodes data as compact binary bytes.

Extra data types — supports Date, ObjectId, Int32, Int64, Binary, Decimal128, and other types JSON can't represent.

Extended JSON — encode with {"$oid"}, {"$date"}, {"$binary"}, {"$numberLong"} and more; decode to relaxed or canonical Extended JSON.

ObjectId generator — insert a fresh ObjectId at the cursor in encode mode.

Hex Dump Diff — compare the Extended JSON text bytes against the BSON bytes byte-for-byte.

Length-prefixed — each document includes its total byte length, enabling fast skipping during scans.

Widely used — MongoDB, Elasticsearch, and many NoSQL databases use BSON as their internal storage format.

100% client-side — everything runs locally with MongoDB's official bson library.

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 Extended JSON into BSON binary, or 'Decode' to convert BSON bytes back to Extended JSON. 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 BSON data.

Insert an ObjectId (encode)

Click 'ObjectId' to insert a fresh {"$oid":"…"} value at the cursor — handy for building test documents with _id fields.

Choose an Output Style (decode)

Leave 'Canonical' unticked for relaxed Extended JSON (readable {"$oid"} and {"$date"} forms), or tick it for canonical output that spells out every number type.

Diff the Bytes

Open the Hex Dump Diff tab to see Extended JSON and its BSON encoding side by side with offset rulers and field-count annotations.

Common Use Cases

MongoDB Document Inspection

Decode BSON documents exported from MongoDB to inspect ObjectId, Date, and Binary values in readable Extended JSON.

Test Fixture Generation

Insert fresh ObjectIds at the cursor to build realistic test documents with _id fields.

Type Mapping Testing

Verify how JSON numbers and strings map to BSON Int32, Int64, Double, and Decimal128 before writing data.

Database Migration

Convert between JSON and BSON when migrating data between MongoDB instances or to different databases.

Wire Protocol Debugging

Inspect raw BSON bytes from MongoDB wire protocol captures during network analysis.

Implementation Examples

JavaScriptJavaScript (MongoDB bson)

import {BSON, EJSON, ObjectId} from "bson";

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

// Round-trip test: doc -> BSON bytes -> doc
const doc = {_id: new ObjectId("507f1f77bcf86cd799439011"), name: "sensor-7", active: true};
const bytes = BSON.serialize(doc);
console.log(toHex(bytes)); // 32000000075f696400507f1f77bcf86cd799439011026e616d65...

const decoded = BSON.deserialize(bytes);
console.log(decoded._id.toHexString()); // 507f1f77bcf86cd799439011

// Extended JSON keeps ObjectId/Date/Binary types portable and readable
const ej = EJSON.stringify(doc, null, 2);
console.log(ej); // {"_id":{"$oid":"507f1f77bcf86cd799439011"},...}

// Back to BSON objects from Extended JSON
console.log(EJSON.parse(ej)._id.toHexString()); // 507f1f77bcf86cd799439011

BSON vs JSON vs MessagePack

Feature	BSON	JSON	MessagePack
Format	Binary	Text	Binary
Data types	Extended (ObjectId, Date, Int64, Decimal128)	Basic (string, number, bool, null, array, object)	Basic + raw bytes, ext types
Self-describing?	Yes (length-prefixed)	No	Partially
Size	Often similar to JSON	Baseline	Compact
Primary use	MongoDB storage	APIs, config	Performance-critical APIs
Parse speed	Fast	Slow	Very fast

Production Best Practices & Security

Use Extended JSON for type fidelity — plain JSON cannot express ObjectId, Date, or Decimal128, so use {"$oid"}, {"$date"}, and {"$numberDecimal"} wrappers when testing MongoDB payloads. Why:BSON round-trips those types exactly, while plain JSON strings lose their meaning — a date that is just a string can never be queried as a date in MongoDB.

Expect BSON to be larger than JSON for small docs — every element carries a type byte and a length prefix. Why:BSON prioritizes fast scanning over compactness. For a handful of short fields the overhead exceeds JSON's text; the hex dump diff shows the exact cost.

Understand the number mapping — JSON integers encode as BSON Int32, Int64, or Double depending on value. Why:{"$numberInt"} stays 32-bit, plain large integers become Int64, and decimals become Double unless you use {"$numberDecimal"} for exact precision. Check the canonical output to see what type each value actually took.

Decode with canonical output to audit types — relaxed output shows numbers plainly, which can hide an Int64-versus-Double mismatch. Why:canonical Extended JSON spells out every type as {"$numberInt"}, {"$numberLong"}, or {"$numberDouble"}, making silent type coercion visible.

ObjectIds are 12 random bytes, not sequential — they embed a 4-byte timestamp but never auto-increment. Why:assuming ascending ObjectIds for ordering can break under concurrency and across processes.

Validate JSON input — ensure your JSON is valid and represents the data types you expect before encoding. Why:BSON encoding of invalid JSON or semantically incorrect data (e.g., a string where a date is expected) will produce valid BSON that silently contains the wrong types, causing bugs downstream when MongoDB or other consumers interpret the data.

Use hex for debugging — hex representation makes it easier to inspect individual bytes and type markers. Why:BSON is a binary format where a single byte change can represent a completely different type or value. Hex encoding makes type codes, field lengths, and byte patterns visible for debugging without corruption from text encoding.

Understand endianness — BSON uses little-endian byte order; be aware when comparing raw bytes across systems. Why:BSON stores multi-byte integers in little-endian order (least significant byte first). Comparing raw BSON bytes on a big-endian system or across different architectures without byte-order conversion will produce incorrect comparisons.

Don't mix BSON versions — MongoDB has evolved BSON over time; ensure compatibility with your target version. Why:Newer BSON types like Decimal128 or Int64 may not be supported by older MongoDB drivers or servers. Using features from a newer BSON specification against an older target will cause deserialization errors or silent data loss.

Frequently Asked Questions

BSON (Binary JSON) is a binary serialization format that extends JSON with additional data types. It was created for MongoDB and serves as both its on-disk storage format and its network transfer protocol.

BSON adds types not available in standard JSON: ObjectId (12-byte unique identifier), Date (64-bit UTC milliseconds), BinData (arbitrary binary blobs), Decimal128 (high-precision decimal), Int32, Int64, and Regular Expressions.

This type richness is why MongoDB queries can work with dates and object IDs natively, while a regular JSON API would need string representations and client-side parsing.

BSON differs from JSON in three key ways.

It is binary — data is encoded in type-length-value format, making it faster to scan and parse.
It supports richer data types including ObjectId, Date, BinData, Decimal128, and Int64, which JSON cannot represent natively.
BSON is slightly larger than JSON on average (due to length prefixes and type markers) but optimized for traversal speed rather than size.

JSON is human-readable and universally supported. BSON is machine-optimized and primarily used in the MongoDB ecosystem.

MongoDB's Extended JSON is the JSON-based notation that represents BSON types plain JSON cannot express:

ObjectId → {"$oid":"507f1f77bcf86cd799439011"}
Date → {"$date":"2023-11-14T22:13:20.000Z"}
Binary → {"$binary":{"base64":"AQID","subType":"00"}}
Decimal128 → {"$numberDecimal":"123.456"}
Int32/Int64 → {"$numberInt":"42"}/{"$numberLong":"9007199254740993"}

Paste any of these forms into the encoder and the tool maps them to the real BSON types; decode renders BSON back into the same Extended JSON notation, either relaxed or canonical.

BSON and CBOR are both binary encodings of JSON-like data, but they serve different worlds.

BSON is tied to MongoDB — it was designed for database traversal speed, and its value is the extra types (ObjectId, Date, BinData, Decimal128, Int64) that map directly onto MongoDB documents. The cost is size: BSON is often about as large as JSON.

CBOR (RFC 8949) is a general-purpose IETF standard optimized for compactness and extensibility. It is typically about 40% smaller than JSON for the same data, supports semantic tags and big numbers, and is used in WebAuthn, COSE, and IoT protocols — no database involved.

Use BSON when your data lives in MongoDB or a MongoDB-compatible store. Use CBOR for APIs, IoT, and any standards-based exchange where wire size matters.

Yes. This tool handles bidirectional conversion — paste BSON binary data (or hex-encoded BSON) to decode it into readable Extended JSON, or paste JSON/Extended JSON to encode it into BSON.

The decoder handles all BSON types including ObjectId, Date, BinData, Decimal128, Int32, Int64, and Regex, presenting them in MongoDB's Extended JSON notation rather than losing them to plain strings.

This is useful for inspecting MongoDB documents exported from a database, debugging wire protocol captures, or converting between formats for analysis.

Paste hex- or base64-encoded BSON data into the input field (or drop a .bson file) and switch to decode. The tool parses the binary format and displays the result as Extended JSON.

It correctly handles all MongoDB-specific types:

ObjectId — displayed as {"$oid"} with a 24-character hex string
Date — shown as ISO 8601
BinData — base64 with subtype
Decimal128, Int32, Int64, and RegExp

Output is relaxed Extended JSON by default; tick Canonical to spell out every number type explicitly. If your BSON comes from a MongoDB export, the tool structures the output for easy inspection.

The encoder accepts both plain JSON and Extended JSON. Plain values map naturally — integers become Int32/Int64, decimals become Double, strings stay strings. Extended forms are understood in relaxed style ({"$date":"2023-11-14T22:13:20.000Z"}, plain numbers) and canonical style ({"$date":{"$numberLong":"1700000000000"}}, {"$numberInt":"42"}), including {"$oid"}, {"$binary"}, {"$numberDecimal"}, {"$numberLong"}, {"$regularExpression"}, and {"$timestamp"}. The document must be a JSON object — BSON cannot encode a bare array as a root document.

Decode mode outputs relaxed Extended JSON by default: {"$oid"} and {"$date":"2023-11-14T22:13:20Z"} forms, with numbers shown plainly. That is the most readable representation for inspection. Ticking Canonical switches to the verbose but lossless form where every type is explicit — numbers render as {"$numberInt"}/{"$numberLong"}/{"$numberDouble"} and dates as {"$date":{"$numberLong":"…"}} — so you can audit exactly which BSON type each value became, including Int64 values too large for a JavaScript number.

Paste a JSON document (or drop a file) and hit Compare bytes. The tool parses it as Extended JSON, encodes it to BSON, and renders two classic hex dumps:

JSON text bytes — the canonical Extended JSON document as UTF-8, every {"$oid"}, quote, brace, and comma visible.
BSON bytes — the binary encoding, annotated with the root document's field count, e.g. document · 3 fields.

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

Yes — that is the core workflow. mongodump/mongosh exports arrive as Extended JSON, which you can paste straight into Encode to get the exact BSON bytes. Decoding a BSON file (from bsondump or a driver) produces the same Extended JSON you started from. ObjectId, Date, Binary, Decimal128, Int64, and RegExp all survive the round trip; only values that exceed JavaScript's safe integer range should be decoded in canonical mode to keep their exact digits.