Visualize MongoDB Documents in a JSON Tree View

You exported one representative document to learn the schema. The tree shows top-level fields and embedded structure at a glance.

doc.json (from mongoexport):
  $ .................... Object(6)
  $._id ............... Object(1)  → { "$oid": "6650a1..." }
  $.email ............. "ada@example.com"
  $.createdAt ......... Object(1)  → { "$date": "2026-05-01T.." }
  $.profile ........... Object(4)
  $.orders ............ Array(2)
  $.tags .............. Array(3)

You now know the document carries _id, email, createdAt,
a profile object, an orders array, and tags.

You want to project just the email-notification preference. Copy the path, drop the $., and you have the MongoDB projection key.

Tree:
  $.profile.preferences.notifications.email ... true

Copy → $.profile.preferences.notifications.email

MongoDB projection:
  db.users.find({}, {
    "profile.preferences.notifications.email": 1
  })

A document references another via an ObjectId. The tree shows the Extended-JSON wrapper; expand it to read and copy the hex value.

  $.orgId ............. Object(1)
  $.orgId.$oid ........ "664f0c9a2b..."

The reference is stored as { "$oid": "..." }. Expand orgId
to copy the hex, then look it up in the orgs collection.
The viewer shows the wrapper as-is — it does not resolve
the reference.

An embedded orders array should have uniform shape, but some elements are missing a field. The tree's child counts flag the inconsistency.

  $.orders ............ Array(2)
  $.orders[0] ......... Object(4)  → id, total, status, paidAt
  $.orders[1] ......... Object(3)  → id, total, status   (no paidAt)

orders[1] has 3 keys vs orders[0]'s 4 — paidAt is missing
on the second order. Classic NoSQL schema drift.

Your app crashes on user.deletedAt. The tree shows whether the field is present-and-null or absent entirely.

  $.deletedAt ......... null      ← present, explicitly null

vs a document where no deletedAt node appears at all
(field omitted). Code must handle both null and missing —
the tree makes which case you're in unambiguous.

mongoexport and Compass write Extended JSON: ObjectIds become {"$oid": "..."} and dates become {"$date": "..."}. The viewer parses strict JSON, so it shows these wrappers literally rather than collapsing them to a native id or Date. Expand the wrapper to read or copy the value — this is expected, not an error.

Copying from the legacy mongo shell can produce ObjectId("...") and ISODate("...") function calls — that's JavaScript, not JSON, so JSON.parse throws. Use mongoexport or Compass's Copy Document (which emit Extended JSON) instead, or convert the shell syntax to strict JSON before viewing.

mongoexport without --jsonArray writes one JSON document per line (NDJSON). The viewer parses the whole file as ONE JSON value, so a multi-line export fails. Re-run with mongoexport --jsonArray to get a single [ ... ] array, then view that.

64-bit and decimal types are written as {"$numberLong": "..."} / {"$numberDecimal": "..."} with the value as a string to avoid precision loss. The tree preserves them exactly — no rounding. Plain JSON numbers, by contrast, are doubles and can lose precision past 2^53.

Deeply embedded subdocuments past the Max depth cap appear as Object(n) / Array(n) with their child count but can't be expanded. Raise Max depth (up to 20) and re-run to drill deeper. No fields are dropped — only child rendering is capped.

Strict JSON allows neither trailing commas nor comments. If you edited the export by hand, clean it up first — json-format-fixer handles both — then view the result.

If an exported object repeats a key, JSON.parse keeps the last occurrence and the tree shows one node. MongoDB documents shouldn't have duplicate keys, so this usually indicates a hand-edit error — check the raw text.

BSON binary appears in Extended JSON as {"$binary": {"base64": "...", "subType": "..."}}. The tree shows the wrapper and the base64 string node; it does not decode the binary. Large base64 blobs also count toward the file-size limit.

Free uploads cap at 2 MB. A single document with embedded binary or large arrays can exceed it. Pro raises the limit to 100 MB; for big multi-document exports, see the large-JSON workflow.

The viewer shows an $oid reference as the stored value; it does not follow it to the referenced document — there's no database connection. Copy the hex and query the referenced collection yourself, or denormalise before exporting.