MongoDB ObjectID Generator & Decoder

What is an ObjectID

A MongoDB ObjectID, written ObjectId in driver APIs, is the default type of the _id field on a document. It is a 12-byte BSON value. In the shell, in JSON exports, and in application logs it is almost always shown as 24 hexadecimal characters. The letters a through f may be upper or lower case; 507F1F77BCF86CD799439011 and 507f1f77bcf86cd799439011 are the same identifier. Drivers also print a wrapper such as ObjectId("507f1f77bcf86cd799439011"). That wrapper is display syntax. The value stored in the collection is the 12 bytes inside the quotes.

Those 12 bytes always sit in the same order, which is why the text form sorts roughly by creation time and why a prefix of the hex string is a clock. The first 4 bytes are a big-endian count of seconds since the Unix epoch, 1970-01-01T00:00:00Z. There are no milliseconds in this field. Two documents created during the same UTC second share the same eight-character prefix even when the rest of the identifier differs. The next 5 bytes are a random value. Current official drivers draw that random value once per process, so identifiers from one process share a process-local prefix and identifiers from different processes do not. The last 3 bytes are a counter. The driver starts the counter at a random value and increments it for every new ObjectID in that process. The counter is what keeps identifiers distinct when many documents are inserted during the same second.

Older drivers placed a machine identifier and a process id in the middle bytes instead of 5 random bytes. You cannot tell those layouts apart from the hex string alone, and you should not treat the middle bytes as a public host address. Together the random portion and the counter are 8 bytes. This generator follows the current layout: cryptographic random bytes for the 5-byte random portion, and an incrementing 24-bit counter for the last 3 bytes. A batch uses one random prefix and then walks the counter, so one click of up to 1,000 identifiers stays unique inside that second. If you generate an ObjectID from a chosen date, that date supplies only the timestamp. The other bytes are still random plus a counter. The result is a syntactically valid ObjectID. It is not evidence that a document with that _id already exists in a database.

An ObjectID is unique enough for ordinary primary keys. Uniqueness comes from the random bytes and the counter, not from the timestamp. Two processes can theoretically collide, and a bug that reuses a counter can collide. MongoDB still uses this layout as the default because the chance is very small for normal applications. It is not a secret. Anyone who can see the hex string can read the embedded second. Do not use an ObjectID as a password, an API key, a session token, or an unguessable link. If a client can read an _id, they can read when that identifier was minted. Authorization still belongs in your application.

Decode an ObjectID's timestamp

Decoding uses only the first eight hex characters, which are the first four bytes. Read them as a hexadecimal integer. That integer is a Unix timestamp in seconds, not milliseconds. Multiply by 1,000 if you need a JavaScript Date. Format the instant in UTC when you want a reading that does not depend on the laptop timezone. This page prints the seconds and a UTC timestamp such as 2012-10-17T21:13:27Z, with the seconds field and no millisecond fraction, because an ObjectID does not store a fraction of a second.

The decoder checks the shape before it reads the time. A value is accepted when it contains exactly 24 hexadecimal characters. Surrounding whitespace is ignored. You can paste several identifiers separated by line breaks, spaces, or commas. A shell wrapper such as ObjectId("507f1f77bcf86cd799439011") is stripped when the inside is 24 hex characters. Anything else is reported on that line, and the other lines are still decoded. Typical failures are a truncated id, a UUID pasted by mistake (36 characters with hyphens), a non-hex letter such as g, and an empty field. The page does not invent a timestamp for an invalid line.

The timestamp is the clock of the process that minted the identifier. It is not the time MongoDB received the insert, and it does not move when the document is updated. If an application sets _id itself, the timestamp is whatever that application wrote, which may have nothing to do with the insert. Clock skew on the generating machine moves the decoded time by the same amount. A decoded time is useful for debugging and for range filters. It is a weak signal when you need an audit timestamp. Store an explicit createdAt date when the business event matters more than the identifier clock.

Example: 507f1f77bcf86cd799439011

The ObjectID 507f1f77bcf86cd799439011 is the sample used throughout the MongoDB documentation. Its first eight hex digits are 507f1f77. Interpreted as a hexadecimal integer, that prefix is the Unix time 1350508407. As a UTC instant that is 2012-10-17T21:13:27Z. The remaining characters, bcf86cd799439011, are the random bytes and the counter from the process that created this particular sample. They do not change the timestamp. Paste the same string into the decoder above. The Unix seconds and the UTC time should match this example, because the page reads those eight hex digits as a Unix second and formats that second in UTC.

Changing any of the first eight characters changes the decoded second. Changing only the last sixteen characters leaves the timestamp at 2012-10-17T21:13:27Z and produces a different ObjectID that happens to share that second. That is the same ordering MongoDB uses when it sorts or ranges on _id. The zero-padded lower bound for this second, which is what ObjectId.createFromTime(1350508407) builds, is 507f1f770000000000000000. Every ObjectID minted during that second is greater than or equal to that bound and less than 507f1f780000000000000000.

{ _id: { $gte: ObjectId.createFromTime(1350508407), $lt: ObjectId.createFromTime(1350508408) } }

Query by date range in MongoDB

Because the timestamp occupies the leading bytes, ObjectIDs compare in time order. A range query on _id can select documents created between two instants without a separate date field. In the MongoDB shell, or in a driver that exposes the helper, ObjectId.createFromTime takes a Unix second and returns an ObjectID whose remaining eight bytes are zero. Use that value as the inclusive lower bound. Use the next second as the exclusive upper bound so you keep every identifier from the start second and none from the following second. For a longer window, pass the start second to $gte and the end second to $lt.

The filter matches documents whose _id is an ObjectID with that timestamp prefix. It does not match a string _id, a UUID, or a numeric _id. It also misses documents that were inserted with an explicit ObjectID whose timestamp was chosen independently of the insert time. If you need a reliable created-at filter, index a real date field and query that field. The _id range is a practical shortcut when you know the application used driver-generated ObjectIDs and you can accept one-second resolution.

The date control on this page produces a full ObjectID at the chosen second, which is useful for fixtures, and it prints the zero-padded lower and upper bounds. A random suffix is the wrong lower bound: it would start the range in the middle of that second and skip earlier inserts. Prefer ObjectId.createFromTime, or the 24-hex value that ends in sixteen zeros, when you write the query. Generate the fixture ids separately if you also need documents to insert.

ObjectID vs UUID vs ULID

ObjectID, UUID, and ULID all identify records, and they make different tradeoffs. An ObjectID is 12 bytes, shown as 24 hex characters, and it is native to MongoDB. A UUID is 16 bytes, shown as 36 characters with hyphens. A ULID is 16 bytes, shown as 26 Crockford Base32 characters. ObjectIDs sort by a second-resolution timestamp. UUID version 4 is random and does not encode a time, so it does not reveal when it was created. UUID version 7 keeps the UUID text format and puts a millisecond timestamp in front. ULID also leads with a millisecond timestamp and sorts as text. NanoID is a compact random string with a configurable alphabet. It does not encode a timestamp, and it is not a BSON ObjectID.

Choose an ObjectID when the collection lives in MongoDB and you want the default _id behavior, including the range query above. Choose UUID v4 when other databases already store a UUID type and you do not want the identifier to reveal a creation time. Choose UUID v7 or ULID when you want sortable identifiers outside MongoDB and you can accept that the creation time is visible. None of these values should be treated as a secret token. A longer comparison of UUID v4, UUID v7, and ULID, including what time-ordering does and does not guarantee, is in the guide UUID v4 vs UUID v7 vs ULID. You can generate the other formats with the UUID generator, the ULID generator, and the NanoID generator. The ID generators category lists every identifier tool on this site.

Rules and limitations

The batch size is a whole number from 1 to 1,000. Values outside that range are pulled back to the nearest allowed count, and the page says so. Each generated line is 24 lowercase hex characters. Unless you chose a date, the first eight characters are the Unix time in seconds at the moment you select Generate.

The decoder accepts a list. Valid lines produce a Unix second and a UTC timestamp. Invalid lines produce an error for that line and do not discard the rest of the list. Blank input produces an error instead of a fake timestamp. Copy and download apply to the generated batch. Download saves a text file with one ObjectID per line. This page does not insert anything into a database.

A date such as 2012-10-17T21:13:27Z, a date-only value such as 2012-10-17, or a whole number of Unix seconds can set the timestamp. Times before 1970 and times that do not fit in an unsigned 32-bit second are rejected. The random bytes come from the browser cryptographic generator. The counter increments inside the batch so those identifiers do not collide with each other.

Common problems

A UUID, a ULID, or a NanoID will not decode as an ObjectID. Check the length and the alphabet. ObjectIDs are 24 hex characters. UUIDs are longer and contain hyphens. ULIDs use a Base32 alphabet. Length is the reliable check. If a decoded time looks an hour off, compare it with UTC. This page prints UTC, not the local timezone of your laptop.

Timestamps before 1970 do not fit the unsigned 4-byte field. Dates after the year 2106 do not fit either. The decoder and the date control report that limit instead of wrapping the clock. Generating thousands of identifiers in one second is fine inside a single batch because of the counter, but this page does not coordinate counters across browser tabs or servers. For production inserts, use your MongoDB driver's ObjectId constructor.

Frequently asked questions

About this tool

Maintained by Toolbench. For large or deeply nested files, split the input into smaller batches and verify representative results before using them in an import or application. Report reproducible problems through Contact.