MongoDB ObjectId generator
This ObjectId generator builds 12-byte BSON ObjectIds with the same layout the MongoDB drivers use, so the values are accepted anywhere an _id of type ObjectId is expected. You can generate them for the current second or for any date an ObjectId can hold (1970-01-01 to 2106-02-07 UTC), which makes it easy to prepare seed data, test fixtures and migration scripts with realistic creation times.
How an ObjectId is built
| Bytes | Hex chars | Content |
|---|---|---|
| 4 | 1–8 | Creation time in seconds since the Unix epoch (big-endian) |
| 5 | 9–18 | Random value, fixed per process (here: per page load) |
| 3 | 19–24 | Counter that starts at a random value and increments for each ID |
Because the timestamp comes first, ObjectIds sort roughly by creation time, which is why sorting by _id in MongoDB approximates insertion order.
Example
With Custom time set to 2024-05-01T12:00:00Z and the ObjectId("…") format, you get output like:
ObjectId("66322ec095a286ddbaccf54a")
ObjectId("66322ec095a286ddbaccf54b")
The first eight hex digits, 66322ec0, are 1714564800 — exactly that date in Unix seconds. The middle part is the same for every ID from this page, and the last three bytes count up by one. Only the timestamp is predictable; your random and counter parts will differ.
Output formats
- Hex string —
6ab7373995a286ddbaccf547, for drivers, REST payloads and CSV imports. - ObjectId("…") — paste straight into
mongoshor a Compass query. - Extended JSON —
{ "$oid": "…" }, the form used bymongoimport,mongoexportand canonical Extended JSON output.
Tips and pitfalls
- Second precision. The timestamp has no milliseconds; all IDs from one batch share it and are ordered by the counter.
- Backdated IDs are still unique. The random and counter bytes differ, so generating many IDs for the same past date does not create duplicates.
- Invalid dates. If the custom time cannot be parsed, the tool asks for a value such as
2024-05-01T12:00:00Z. Include theZor an offset to avoid local-time surprises. A date before 1970 or after 2106-02-07 does not fit the 32-bit seconds field and is rejected with an error.
To check what an existing ID contains, use the ObjectId to timestamp decoder. The Unix timestamp converter helps when you need the seconds value for a date.
Querying by creation date with a generated ID
Because the timestamp sits in the first four bytes, you can use an ObjectId as a date boundary without storing a separate createdAt field. Generate an ID for the start date, keep the first eight hex digits and replace the rest with zeros:
// documents created on or after 2024-05-01T12:00:00Z
db.orders.find({ _id: { $gte: ObjectId("66322ec00000000000000000") } })
The zeroed tail is the smallest possible value for that second, so the query includes every document created from then on. This works well for quick checks and exports. For reports that need exact times or time zones, a real date field is still the better choice, since the ObjectId only records whole seconds from the client or driver that created it.
Privacy
IDs are generated in your browser with crypto.getRandomValues for the random and counter bytes. No request is made to a server or a database.