JSON vs BSON: Differences, Tradeoffs, and When to Use Each

Q: What is BSON used for?

BSON (Binary JSON) is primarily used by MongoDB as its native storage and wire format. When you insert a document into MongoDB, it is stored as BSON internally. When MongoDB communicates between the client driver and the server, it sends BSON over the wire. BSON was designed by MongoDB Inc. specifically for document databases — it is optimized for fast field traversal and supports additional types that plain JSON lacks, such as ObjectId (MongoDB document identifiers), native Date, binary data, 64-bit integers, and Decimal128 for high-precision numbers. Outside MongoDB, BSON sees limited use.

Q: Is BSON always smaller than JSON?

No. BSON is not always smaller than JSON and sometimes it is larger. BSON stores type information and length prefixes alongside every value, which adds overhead. For small documents with short string values and simple types, BSON can be larger than equivalent JSON. BSON becomes more space-efficient than JSON for documents containing binary data (which JSON must base64-encode, adding ~33% overhead), 64-bit integers (which JSON encodes as strings to avoid precision loss), and when field traversal speed matters more than storage size. Do not choose BSON over JSON for the purpose of compression — use gzip for that instead.

Q: Does BSON support types that JSON does not?

Yes. BSON supports several types that JSON cannot represent natively. ObjectId is a 12-byte identifier used as the default MongoDB document ID. Date is a native 64-bit UTC datetime, not a string. Binary is raw byte arrays, not base64 strings. Int32 and Int64 are explicit integer types that preserve 64-bit precision. Decimal128 is a 128-bit decimal number for financial calculations. Regex stores regular expression patterns with their flags. Min/MaxKey are special comparison values. In JSON, all of these require encoding conventions — dates as ISO strings, binary as base64, large integers as strings to avoid IEEE 754 precision loss.

Q: Which is faster: JSON or BSON?

BSON is faster than JSON for field traversal and random access within a document, because each value is prefixed with its byte length, allowing a parser to skip directly to any field without reading intermediate content. JSON parsers must read every character in sequence to find a specific field. For MongoDB queries that access only a few fields from large documents, BSON provides measurable speedups. However, for serializing and deserializing full documents, JSON is often comparable in speed or faster for small payloads because JSON parsers are extremely well optimized, especially in JavaScript where JSON.parse is a native engine function.

Q: When should I use BSON over JSON?

Use BSON when you are working directly with MongoDB — the driver handles BSON automatically, so you rarely interact with it directly. Use BSON when you need to store binary data without the ~33% size overhead of base64 JSON strings. Use BSON when your data includes native dates that must be queried by range without string parsing, or when you need 64-bit integer precision that JSON cannot guarantee. For everything else — public APIs, config files, browser data, logs, and data interchange between systems — JSON is simpler, universally supported, and human-readable.

Q: Does BSON support Date natively?

Yes. BSON has a native Date type that stores a 64-bit signed integer representing milliseconds since the Unix epoch (January 1, 1970 UTC). This allows MongoDB to index, query, and sort date fields efficiently without string parsing. When you insert a JavaScript Date object through the MongoDB Node.js driver, it is automatically stored as a BSON Date. When you read it back, it is returned as a Date object. In contrast, JSON has no date type — dates are stored as strings and must be parsed by the application. The native BSON Date type is one of the most practically useful features for database workloads.

Last updated: May 11, 2026

JSON is a UTF-8 text format; BSON (Binary JSON) is a binary serialization of JSON-like documents designed for efficient storage and traversal. BSON adds 4 types that JSON lacks: Date (64-bit UTC milliseconds), Binary (arbitrary bytes), ObjectId (12-byte MongoDB ID), and Decimal128 (precise 128-bit decimal). BSON is typically 10–30% larger than the equivalent JSON for small documents, but supports faster field extraction without full parsing. MongoDB stores BSON internally and converts to JSON over the wire. This guide covers the type differences, size tradeoffs, and when BSON is the better choice.

Quick comparison

Feature	JSON	BSON
Format	UTF-8 text	Binary
Human readable	Yes	No, needs a decoder
Common use	APIs, config, files	Document storage, MongoDB wire/storage format
Extra types	Limited JSON primitives	Date, ObjectId, binary, decimal, int types
Debugging	Easy in editors and browsers	Use database tools or conversion output

Same document concept

BSON represents JSON-like documents, but it can preserve values that plain JSON cannot represent without conventions.

{
  "name": "Alice",
  "createdAt": "2026-04-30T10:00:00.000Z",
  "active": true
}

In JSON, createdAt is a string. In BSON, a date can be stored as a native BSON date type. That distinction matters when querying and indexing database documents.

When to use JSON

Public APIs where clients need a portable text response.
Config and fixtures that developers edit by hand.
Browser workflows where JSON.parse and JSON.stringify are built in.
Logs and debugging where readable output is more valuable than binary fidelity.

When BSON makes sense

MongoDB documents that need ObjectId, Date, binary, or decimal types.
Database internals where fast field traversal matters.
Binary payloads where base64-encoded JSON would add overhead.
Storage engines that need type metadata next to the value.

Common migration mistake

Do not treat BSON as "compressed JSON." BSON can be larger than equivalent JSON because it stores type markers and length prefixes. Its value is type fidelity and traversal, not guaranteed smaller files.

Inspect the JSON version first

When debugging data that came from a document database, export the document as JSON and use Jsonic's JSON Formatter to validate and inspect the structure before converting or importing it elsewhere.

Open JSON Formatter

Frequently asked questions

What is BSON used for?

BSON is MongoDB's native storage and wire format. It was designed for document databases to enable fast field traversal and to support additional types like ObjectId, native Date, binary data, 64-bit integers, and Decimal128. Outside MongoDB, BSON sees very limited use.

Is BSON always smaller than JSON?

No. BSON stores type markers and length prefixes alongside each value, which can make it larger than equivalent JSON for small documents with simple types. BSON is more efficient for binary data, 64-bit integers, and fast field access — not for general compression.

Does BSON support types that JSON does not?

Yes. BSON adds ObjectId, native Date (64-bit UTC milliseconds), binary byte arrays, Int32, Int64, Decimal128, and Regex types. JSON must encode all of these as strings or use conventions, losing type fidelity and precision for 64-bit integers.

Which is faster: JSON or BSON?

BSON enables faster random field access because length prefixes let the parser skip directly to any field. For full document serialization, JSON is often comparable since JSON.parse is a highly optimized native function in JavaScript engines.

When should I use BSON over JSON?

Use BSON when working with MongoDB (the driver handles it automatically), storing binary data without base64 overhead, querying native date ranges, or needing 64-bit integer precision. For APIs, config, logs, and data interchange, JSON is simpler and universally supported.

Does BSON support Date natively?

Yes. BSON Date is a 64-bit signed integer of milliseconds since Unix epoch. MongoDB uses it to efficiently index, query, and sort date fields. JavaScript Date objects are automatically converted by the MongoDB driver. JSON has no date type — dates are always strings.