JSON to BSON / Extended JSON Converter

MongoDB drivers and mongoexport emit Extended JSON (EJSON) so BSON-only types (ObjectId, Date, Decimal128, BinData, NumberLong) survive a JSON round trip. This converter goes both ways: plain JSON to EJSON v2 (canonical and relaxed) for upload via mongoimport, or EJSON to plain JSON for downstream tools that only speak strict JSON.

How to use the JSON to BSON / Extended JSON Converter

JSON→EJSON: paste plain JSON, get out Extended JSON with type wrappers around values that need them ({ "$oid": "..." } for ObjectIds, { "$date": "..." } for dates, { "$numberLong": "..." } for 64-bit ints). Relaxed mode keeps numbers and dates in JSON-friendly form; canonical mode wraps everything for lossless type preservation — use canonical when round-tripping or storing schema snapshots.

EJSON→JSON: paste Extended JSON, get plain JSON with type wrappers unwrapped to native values. ObjectIds become their hex string, dates become ISO 8601 strings, long numbers stay as numbers if they fit JavaScript’s number range or become strings if they don’t.

About JSON to BSON / Extended JSON Converter

BSON — Binary JSON — is MongoDB’s on-disk and on-the-wire format. It extends JSON with types that JSON lacks: native dates, 64-bit integers, 128-bit decimals, binary blobs, ObjectIds, regular expressions. Extended JSON (EJSON) is the textual representation that round-trips those types through anything JSON-aware: each non-JSON type becomes a one-key object using a $-prefixed marker. ObjectId 5f8d0a2a8a9f8b1c8d3e4f5a becomes { "": "5f8d0a2a8a9f8b1c8d3e4f5a" }; a Date becomes { "": "2026-01-15T10:00:00Z" }; a 64-bit int becomes { "": "9007199254740993" }.

There are two flavours. Relaxed mode (the default for mongoexport) keeps numbers and dates in JSON-friendly form where possible — small ints stay as numbers, dates round-trip as ISO strings. Canonical mode wraps everything for guaranteed lossless round-tripping. Use relaxed for human readability and most ETL; use canonical for backups and snapshots where exact byte-for-byte preservation matters.

Common use cases

  • Hand-editing MongoDB import data — detect ObjectIds and dates in your hand-written JSON before mongoimport rejects them.
  • Bridging Mongo to non-Mongo systems — strip EJSON wrappers when sending data to Elasticsearch, Postgres, or any tool that wants plain JSON.
  • Migrating between EJSON v1 and v2 — modernise old mongoexport outputs into the current canonical format.
  • Debugging change streams — convert raw change-stream JSON for easier inspection in non-Mongo tools.

Frequently asked questions

What is the heuristic for detecting ObjectIds?
Exactly 24 hex characters (case-insensitive). Most ObjectIds match this pattern; if you have hex strings that aren't ObjectIds, untick the option or wrap them in a non-string field name.

How are very large numbers handled?
JavaScript safely represents integers up to 2^53 - 1. Beyond that, canonical mode emits { "$numberLong": "..." } with the value as a string to avoid precision loss. Relaxed mode keeps it as a number where safe.

Does it handle Decimal128?
On the EJSON-to-JSON path, { "$numberDecimal": "..." } unwraps to a string (since JavaScript has no native Decimal128). The JSON-to-EJSON path doesn't auto-detect decimals \xE2\x80\x94 wrap manually if you need exact decimal storage.