BYTETOOLS

MongoDB ObjectId Decoder

Decode a MongoDB ObjectId into its timestamp, random value and counter, and build a boundary ObjectId for date-range _id queries.

2012-10-17T21:13:27.000Z
Created (UTC)
—
Age

The three parts of an ObjectId

507f1f77bcf86cd799439011

Bytes 0–3 — timestamp
507f1f77 = 1350508407 seconds since the Unix epoch (big-endian)
ISO 8601 (UTC)
2012-10-17T21:13:27.000Z
Local time
—
Bytes 4–8 — random value
bcf86cd799
Bytes 9–11 — counter
439011 = 4427793

Since MongoDB 3.4 the middle five bytes are a per-process random value generated once at start-up, not the machine identifier plus process ID used by older drivers. The last three bytes are a counter that starts at a random number and increments for every ObjectId that process creates.

Build a boundary ObjectId for a date

Pick a date between 1970 and 2106 to generate a boundary ObjectId.

What is the MongoDB ObjectId Decoder?

The ByteTools MongoDB ObjectId Decoder splits a 24-character ObjectId into the three parts the driver packs into it: a 4-byte big-endian count of seconds since the Unix epoch, a 5-byte per-process random value, and a 3-byte incrementing counter.

  • Splits the ObjectId into timestamp, random value and counter
  • Creation time in ISO 8601 UTC, local time and relative age
  • Colour-coded hex showing each byte range
  • Builds a boundary ObjectId for any date
  • Copyable find query for _id range filtering
  • 100% client-side — document IDs never leave your browser

How to use the MongoDB ObjectId Decoder

  1. 1

    Paste an ObjectId into the box — a bare 24-character hex string or the full ObjectId wrapper both work.

  2. 2

    Read the creation date in UTC, your local time, and as an age.

  3. 3

    Study the colour-coded hex to see which bytes are the timestamp, the random value and the counter.

  4. 4

    Use the builder at the bottom to turn any date into a boundary ObjectId, then copy the ready-made range query.

About the MongoDB ObjectId Decoder

The ByteTools MongoDB ObjectId Decoder splits a 24-character ObjectId into the three parts the driver packs into it: a 4-byte big-endian count of seconds since the Unix epoch, a 5-byte per-process random value, and a 3-byte incrementing counter. The creation time is shown in ISO 8601 UTC and in your local time zone, with a plain-English age.

Because the timestamp lives in the leading bytes, ObjectIds sort by creation time. The builder at the bottom exploits that: pick any date and it produces the smallest possible ObjectId for that moment, ready to paste into a $gte or $lt filter so you can query by date without adding a createdAt field.

All parsing happens 100% locally in your browser and nothing is uploaded. ObjectIds identify real documents in real collections, so it is worth keeping them off other people's servers by default. The tool is plain client-side JavaScript with no network calls, which means it also keeps working offline once the page has finished loading.

Frequently asked questions

How do I get the creation date from a MongoDB ObjectId?

The first four bytes — the first eight hex characters — are the number of seconds since 1 January 1970, stored big-endian. Paste the ObjectId here and the date appears immediately. In the shell you can also call getTimestamp() on the ObjectId to get the same value.

Can I query MongoDB by date using only _id?

Yes. Because the timestamp sits in the leading bytes, ObjectIds sort chronologically. Build a boundary ObjectId for your cut-off date and use it in a $gte filter on _id. It is a common way to page through history when a collection has no createdAt field.

What are the middle five bytes of an ObjectId?

Since MongoDB 3.4 they are a random value generated once per process when it starts. Older drivers used a machine identifier plus a process ID instead. Either way they exist to keep two processes from colliding within the same second, and they carry no meaning you can decode.

How precise is the ObjectId timestamp?

One second. Only whole seconds are stored, so every document created within the same second shares a timestamp and is ordered by the counter instead. If you need millisecond precision, store an explicit date field rather than relying on _id.

Is my ObjectId uploaded anywhere?

No. The decoding is straightforward hex parsing done in your browser, and the page makes no network requests, so production document IDs stay on your machine.

Related tools