Guide
Reading the creation time inside a MongoDB ObjectId
Every document in a MongoDB collection has an _id, and unless you supply your own it is an ObjectId: a compact 12-byte identifier that the driver creates before the document ever reaches the database. Because its first four bytes are a timestamp, an ObjectId doubles as a record of roughly when the document was made, which is handy for debugging and for date-range queries. This page splits an ObjectId into its parts and builds new ones.
The three parts
The 24 hexadecimal characters break down as follows. The first eight characters, four bytes, are the number of seconds since 1 January 1970 UTC, stored as a big-endian integer. The next ten characters, five bytes, are a random value generated once per process, which separates identifiers made by different machines or processes. The last six characters, three bytes, are a counter that starts at a random number and increases with each id the process creates.
Decoding
Paste ObjectIds one per line. The table lists each with its creation time in UTC, the Unix seconds, the random part and the counter as a number. The wrapper ObjectId(“…”) from the mongo shell is accepted, and uppercase digits are fine. A line that is not 24 hexadecimal characters gives a message with the reason, such as the wrong length. A column of Unix seconds is included because that number is what you would compare against other systems.
Generating and building ids
The “Generate a new ObjectId” button creates an id with the current time, your browser’s secure random bytes for the random part and a counter, and keeps the latest ten in a list. The date box builds the smallest ObjectId for a given moment: the eight time digits followed by sixteen zeros. Enter an ISO date such as 2024-01-15T09:30:00Z and copy the result. Dates before 1970 or after the year 2106 cannot fit the four bytes and are rejected.
Accuracy of the date
The time is the clock of the machine that generated the id, taken when the driver created it, usually the application server and not the database. If that clock was wrong, so is the date. It also shows when the id was made and not when the document was inserted, which can be later if the application held it back. Ids from a different generator, or custom _id values that only look like ObjectIds, decode into nonsense dates.
A worked example
The Sample button loads three ids. The first, 507f1f77bcf86cd799439011, is the example used in the MongoDB documentation. Its first eight digits, 507f1f77, are 1,350,508,407 seconds, which is 2012-10-17 21:13:27 UTC. The random part is bcf86cd799 and the counter is 439011, which is 4,427,793 in decimal. The second, 65a1b2c3d4e5f60718293a4b, decodes to 2024-01-12 21:44:35 UTC. Building the lowest id for 2024-01-15T09:30:00Z gives 65a4fb180000000000000000.
Limits
The random and counter parts do not carry meaning beyond uniqueness, and the page cannot tell which machine made an id. The generator here is for tests and examples; real applications should let the driver or the database create ids. Only the classic 12-byte structure is decoded, not other id types such as UUIDs or ULIDs, which have their own tools.
Related tools
- ULID Generator makes sortable ids with a millisecond timestamp.
- UUID Generator creates standard universally unique identifiers.
- Snowflake ID Decoder reads time-based 64-bit ids.
- Timestamp Converter converts the Unix seconds to and from dates.
Checked against the current version of the ObjectId Decoder on .