Understanding MongoDB ObjectId: Structure, Timestamps, and Alternatives

Maria
MongoDB
28 Sep, 2026

Insert a document into MongoDB without an _id and one appears automatically: something like ObjectId("66f8a3c2e4b0a1d2c3f4e5a6"). Most developers treat it as an opaque random string, copy it into URLs, and move on. That works, but it leaves useful information on the table and occasionally leads to bugs, like comparing an ObjectId to a string and wondering why the query finds nothing.

An ObjectId is a small, carefully designed value: 12 bytes that can be generated on any machine without coordination, sort roughly by creation time, and carry their own timestamp. Understanding that structure helps you use it well, and helps you recognize when a different identifier (a UUID, a natural key, or a short public ID) is the better fit.

This guide covers the anatomy of an ObjectId, extracting and querying by its timestamp, sorting behaviour, working with ObjectIds in drivers, and the alternatives, with their trade-offs.

The _id Field

Every document in a MongoDB collection has an _id field. It's the primary key: it must be unique within the collection, it's automatically indexed, and it can't be changed after insertion. If you don't provide one, the driver (or server) generates an ObjectId for you.

_id doesn't have to be an ObjectId. It can be any BSON type except an array: a string, a number, a UUID, even an embedded document. ObjectId is simply the default because it solves the "generate a unique ID anywhere, fast" problem well.

Anatomy of an ObjectId

An ObjectId is 12 bytes, usually shown as 24 hexadecimal characters:

66f8a3c2  e4b0a1d2c3  f4e5a6
|------|  |--------|  |----|
 4 bytes    5 bytes   3 bytes
timestamp   random    counter

Bytes	Content
0–3	Seconds since the Unix epoch, big-endian
4–8	A random value, generated once per process
9–11	A counter, starting from a random value, incremented per ID

Older documentation described the middle bytes as a machine identifier plus a process ID. The current specification replaced that with a per-process random value, which avoids collisions in containers where many processes share the same hostname and PID.

This design gives you a few useful properties:

Decentralized generation. Any client can create an ID without asking the server, and the random-plus-counter portion makes collisions practically impossible.
Approximate time ordering. The timestamp comes first, so IDs created later generally sort after IDs created earlier.
Compactness. 12 bytes is smaller than a 16-byte UUID or a 36-character UUID string.

Who Generates It?

In almost every case, the driver creates the ObjectId before sending the insert. That's why insertOne can return insertedId immediately, and why the timestamp reflects the application server's clock rather than the database's. If your app servers have skewed clocks, their ObjectIds will reflect that skew.

Extracting the Timestamp

Because the first four bytes are a timestamp, every ObjectId carries its creation time for free:

const id = ObjectId("66f8a3c2e4b0a1d2c3f4e5a6");
id.getTimestamp();
// ISODate("2024-09-29T00:48:02.000Z")

In the Node.js driver:

import { ObjectId } from "mongodb";

const id = new ObjectId("66f8a3c2e4b0a1d2c3f4e5a6");
console.log(id.getTimestamp().toISOString()); // 2024-09-29T00:48:02.000Z

And in PyMongo, via the bson package that ships with it:

from bson import ObjectId

oid = ObjectId("66f8a3c2e4b0a1d2c3f4e5a6")
print(oid.generation_time)  # 2024-09-29 00:48:02+00:00 (timezone-aware UTC)

In an aggregation pipeline, $toDate converts an ObjectId to its embedded date:

db.orders.aggregate([
  { $project: { createdAt: { $toDate: "$_id" } } },
  { $limit: 3 },
]);

Should You Skip a createdAt Field?

It's tempting to drop createdAt since _id already contains it. Resist that for most applications:

The precision is one second. Anything needing milliseconds needs its own field.
It only works when _id is an ObjectId generated at creation time. Imported or migrated data may have IDs generated later, or not be ObjectIds at all.
Explicit fields are clearer to other developers, to BI tools, and to your future self.

A dedicated createdAt costs 8 bytes and removes ambiguity. The embedded timestamp is still great for debugging, ad hoc analysis, and the range trick below.

Querying by Time Using _id

Since ObjectIds sort by their leading timestamp, you can build an ObjectId from a date and use it for a range query on _id, which is always indexed:

function objectIdFromDate(date) {
  const seconds = Math.floor(date.getTime() / 1000).toString(16);
  return ObjectId(seconds.padStart(8, "0") + "0000000000000000");
}

db.events.find({
  _id: {
    $gte: objectIdFromDate(new Date("2026-09-01T00:00:00Z")),
    $lt: objectIdFromDate(new Date("2026-09-02T00:00:00Z")),
  },
});

The Node.js driver has a built-in helper:

const start = ObjectId.createFromTime(
  Date.parse("2026-09-01T00:00:00Z") / 1000,
);

PyMongo has ObjectId.from_datetime(dt). These synthetic IDs are for comparisons only: never insert them, since the zeroed random and counter bytes make them non-unique.

This technique is handy on collections where you don't have (or didn't index) a date field. If you do have an indexed createdAt, querying it directly is clearer.

Sorting and Ordering

Sorting by _id is a cheap way to get "roughly newest first" without another index:

db.posts.find().sort({ _id: -1 }).limit(20);

It's also the basis of efficient range-based pagination: remember the last _id you returned and ask for { _id: { $lt: lastId } } on the next page. That's far faster than large skip() values on big collections, and it's covered in detail in the guide to pagination in MongoDB.

Be clear about the limits of that ordering, though:

Within the same second, order depends on the random value and counter, so IDs from different processes interleave arbitrarily.
Clock skew between app servers can make a later insert get an earlier ObjectId.
It reflects when the ID was generated, not when the write was committed.

For "roughly chronological" feeds and pagination, that's fine. For anything requiring strict ordering (ledgers, event sequences), use an explicit sequence number or timestamp field.

Working with ObjectIds in Application Code

Strings Are Not ObjectIds

The most common ObjectId bug: an ID arrives from a URL or JSON body as a string, and the query compares it to an ObjectId field.

// matches nothing: the stored _id is an ObjectId, not a string
await users.findOne({ _id: req.params.id });

// correct
await users.findOne({ _id: new ObjectId(req.params.id) });

BSON types are compared strictly, so a string never equals an ObjectId, even with the same hex characters. Convert at the boundary of your application.

Validate Before Converting

new ObjectId("not-an-id") throws. Validate user input first and return a 400 or 404 instead of a 500:

import { ObjectId } from "mongodb";

const OBJECT_ID_RE = /^[0-9a-f]{24}$/i;

app.get("/users/:id", async (req, res) => {
  const { id } = req.params;
  if (!OBJECT_ID_RE.test(id)) {
    return res.status(404).json({ error: "Not found" });
  }
  const user = await users.findOne({ _id: new ObjectId(id) });
  if (!user) return res.status(404).json({ error: "Not found" });
  res.json(user);
});

A strict 24-character hex check is the clearest rule for URL input. ObjectId.isValid() also exists, but its exact behaviour for edge cases (such as 12-byte inputs) has varied between bson library versions, so a regex keeps the contract explicit.

In Python:

from bson import ObjectId
from bson.errors import InvalidId

def parse_object_id(value: str) -> ObjectId | None:
    try:
        return ObjectId(value)
    except (InvalidId, TypeError):
        return None

Serializing to JSON

JSON.stringify on an ObjectId in the Node.js driver produces the hex string, which is usually what an API wants. Mongoose exposes a string id virtual alongside _id. In Python, json.dumps fails on ObjectId, so either convert with str(oid) or use bson.json_util.dumps, which produces MongoDB Extended JSON like {"$oid": "66f8..."}. Pick one representation for your API and apply it consistently.

Is Exposing ObjectIds a Security Problem?

ObjectIds aren't secrets, and they aren't meant to be. Two things are worth knowing:

They reveal creation time. Anyone with the ID knows when the record was created, to the second. For most resources that's harmless. For some (a user account, an internal report) it may leak information you'd rather keep private.
They're partly predictable. Within one process, the counter increments, so IDs generated close together are similar. They're not designed to be unguessable.

Neither should matter if your API performs authorization checks on every request. An ID tells you which record someone wants; your code decides whether they're allowed to have it. If you rely on IDs being hard to guess (for share links, password reset tokens, or invitation codes), generate a proper random token instead.

Alternatives to ObjectId

UUIDs

UUIDs are 128-bit identifiers widely used across systems. Store them as BSON Binary subtype 4, not as strings, to save space and index size:

db.accounts.insertOne({ _id: UUID(), name: "Acme" });
// { _id: UUID("3b241101-e2bb-4255-8caf-4136c566a962"), name: "Acme" }

In the Node.js driver, new UUID() from the mongodb package produces the right type. In PyMongo, set uuidRepresentation="standard" on the client and pass uuid.uuid4() values.

Random (version 4) UUIDs have one downside: inserts land at random positions in the _id index, which can hurt cache efficiency on very large collections. Time-ordered UUIDv7 keeps the global uniqueness of a UUID while sorting by time like an ObjectId. Driver support for generating v7 varies, so check your language's libraries.

Natural Keys

If a value is genuinely unique and immutable, using it as _id saves an index and a lookup:

db.countries.insertOne({ _id: "GB", name: "United Kingdom" });
db.dailyStats.insertOne({
  _id: { site: "blog", day: "2026-09-28" },
  views: 1804,
});

The second example uses a compound _id, which makes upserts of daily aggregates trivially idempotent. Just remember that _id can never change, so don't use email addresses, usernames, or anything a user can edit. And for embedded-document keys, field order matters in equality comparisons.

Auto-Incrementing Integers

MongoDB has no built-in auto-increment. You can emulate one with a counters collection:

function nextSequence(name) {
  const doc = db.counters.findOneAndUpdate(
    { _id: name },
    { $inc: { seq: 1 } },
    { upsert: true, returnDocument: "after" },
  );
  return doc.seq;
}

db.invoices.insertOne({ _id: nextSequence("invoice"), total: 250 });

This costs an extra write per insert, creates a hot document under heavy load, and can leave gaps if an insert fails after the counter increments. Use it when humans need sequential numbers (invoice numbers are often a legal requirement), ideally as a separate field alongside a normal _id.

Short Public IDs

For URLs, many apps keep ObjectId as the internal _id and add a short, random, uniquely indexed publicId (generated with a library like nanoid). That gives you friendly URLs without leaking creation times, and it decouples your public identifiers from your storage layout.

Choosing Between Them

Option	Size	Time-ordered	Best for
ObjectId	12 bytes	Roughly	The default for most collections
UUIDv4 (Binary)	16 bytes	No	Interop with systems that already use UUIDs
UUIDv7 (Binary)	16 bytes	Yes	UUID interop with index-friendly inserts
Natural key	Varies	No	Immutable unique values, idempotent upserts
Integer sequence	4–8 bytes	Yes	Human-facing numbers like invoices

Common Pitfalls

Comparing strings to ObjectIds. A string _id in a filter never matches an ObjectId field. Convert input with new ObjectId() after validating it.

Storing ObjectIds as strings in references. If orders.customerId holds a string while customers._id is an ObjectId, $lookup joins return nothing and every query needs a conversion. Store references with the same type as the key they point to.

Treating the embedded timestamp as authoritative. It has second precision and reflects the client's clock at generation time. Keep an explicit createdAt for business logic.

Using ObjectIds as security tokens. They're unique, not unguessable. Use cryptographically random tokens for anything that grants access.

Storing UUIDs as strings. A 36-character string takes more than twice the space of Binary subtype 4 and makes indexes larger. Configure your driver to use the standard binary representation.

Conclusion

An ObjectId packs a timestamp, a per-process random value, and a counter into 12 bytes, giving you IDs that are unique without coordination, roughly time-ordered, and cheap to index. You can extract its creation time, use it for time-range queries and range-based pagination, and sort by it for a quick "newest first". It isn't a secret, and it isn't a precise clock, so pair it with explicit fields and real authorization checks.

Check how your API handles an invalid ID in a URL today. If /users/banana returns a 500, add a 24-character hex check at the route boundary so it returns a clean 404 instead.