What is the structure of a MongoDB ObjectId?

An ObjectId is 12 bytes, written as a 24-character hex string. Reading left to right: bytes 0 to 3 are a 32-bit Unix timestamp in whole seconds, bytes 4 to 8 are 5 random bytes set once per process, and bytes 9 to 11 are a 3-byte counter that ticks up for each new id. For example in 65f1a2b3c4d5e6f708192a3b the leading 65f1a2b3 is the time, c4d5e6f708 is the random field, and 192a3b is the counter.

How do I get the creation time out of an ObjectId?

Take the first 8 hex characters (the first 4 bytes), read them as a big-endian integer, and that is the Unix time in seconds. So 65f1a2b3 is 1710334643, which is 2024-03-13 12:57:23 UTC. Paste any ObjectId into the decoder above and it shows the seconds value, the UTC time and your local time. The resolution is one second, not millisecond, because the timestamp field only holds whole seconds.

What is the difference between an ObjectId and a UUID?

A v4 UUID is 128 random bits with no readable time inside it; a MongoDB ObjectId is 96 bits with a second-resolution timestamp in the leading 4 bytes. That means an ObjectId tells you when the document was inserted and roughly sorts by creation order, while a random UUID tells you nothing about time. If you want millisecond ordering in a UUID column instead, look at UUIDv7 or ULID, which both embed a millisecond timestamp.

How do I query a MongoDB time range using ObjectId bounds?

Build the smallest ObjectId for the start second and the largest for the end second, then query { _id: { $gte: low, $lte: high } }. The bounds tool above gives you both edges for any time you pick: the low edge zeroes the random and counter bytes, the high edge maxes them out. Because _id is already indexed this range scan is fast and needs no separate createdAt index. Example: all documents from 2024-03-13 12:57:23 start at 65f1a2b30000000000000000.

Is an ObjectId globally unique?

It is unique in practice but not by a hard mathematical guarantee like a UUID. Uniqueness comes from three parts working together: the timestamp separates different seconds, the 5 random bytes separate different processes and machines, and the counter separates ids made within the same second by one process. A collision needs the same second, the same random field and a wrapped counter at the same instant, which is vanishingly unlikely for normal workloads.

Are these ObjectIds safe to use as real database keys?

Yes. They follow the same 12-byte layout the official MongoDB drivers use, the random bytes come from the browser crypto API rather than a weak Math.random, and within one batch the counter increments so the ids sort in generation order. The only difference from a live driver is that this tool reseeds the random field per batch instead of per long-lived process, which is exactly what you want for one-off scripts and test fixtures.

Debug a document by reading its insertion time

You pull a record out of a collection and want to know when it was created, but there is no createdAt field. Paste the _id into the decoder and you get the exact second the document was inserted, in UTC and your local time. No extra query, no schema change — the clock was in the primary key the whole time.

Backfill or migrate documents in a time window

A migration script needs every document created on a given day. Build the lowest ObjectId for the start of that day and the highest for the end, then query _id between those bounds. Because _id is already indexed the scan is fast, and you avoid adding a temporary createdAt index just to slice by time.

Generate stable ObjectIds for test fixtures

Your integration tests need a handful of realistic _id values that look like the real thing and sort in a predictable order. Generate a batch, copy them into your seed file, and the counter increment keeps them strictly ascending so any "order by _id" assertion stays stable across runs.

Explain ObjectId structure to a teammate

Onboarding someone who has only seen auto-increment integer keys? Generate one ObjectId, decode it, and walk through the timestamp, random and counter bytes live. The shareable URL reopens the exact id and decoded view, so you can drop it into a chat message and have them see what you see.

MongoDB ObjectId Generator and Timestamp Decoder

Generate ObjectIds, decode the embedded timestamp, build $gte/$lte bounds for a time range — all in your browser

Runs locally
Category Developer & DevOps
Best for Formatting, validating, shrinking, or inspecting code-adjacent text.

A MongoDB ObjectId is 12 bytes shown as 24 hex chars: a 4-byte second-resolution timestamp, 5 random bytes, then a 3-byte counter. The leading bytes are the creation time, so the _id alone tells you when a document was inserted.

How many

Uppercase

Generated ObjectIds

Click Generate to mint ObjectIds.

Decode an ObjectId

The decoded creation time shows up here.

ObjectId bounds for a point in time

Pick a time and get the lowest and highest ObjectId for that second — paste them into a Mongo $gte / $lte range query.

At this time

What this tool does

A MongoDB ObjectId generator and decoder that runs entirely in your browser. An ObjectId is the 12-byte value MongoDB drops into the _id field by default, shown as a 24-character hex string. Its layout is fixed: 4 bytes of Unix timestamp in whole seconds, 5 random bytes generated once per process, then a 3-byte counter. This tool mints fresh ObjectIds in batches of 1 to 100 using crypto-grade randomness, decodes any ObjectId you paste back into its creation time (seconds, UTC and your local zone), and builds the lowest and highest ObjectId for a chosen second so you can run a fast _id range query instead of scanning a createdAt column. Every byte is computed locally with plain JavaScript, nothing is uploaded, and a shareable URL carries your settings and the id you are inspecting. Ideal for debugging documents, scripting backfills and reading the clock that is already baked into your primary key.

Tool details

Input: Numbers; The page exposes text boxes, numeric controls, file pickers, or structured inputs depending on the tool.
Output: Live result + Copy + Download; The result area focuses on usable output, with copy, download, or preview actions when supported.
Privacy: Browser-side processing; The main tool logic does not call an external API, so inputs normally stay in the current tab.
Save / share: Shareable URL state; Key settings are encoded in the URL so another person can reopen the same setup.
Performance budget: Initial JS <= 9 KB; No WASM budget is declared, keeping the tool quick to open on mobile.
Best fit: Developer & DevOps · Developer; Category and role tags drive related tools, internal links, and quick fit checks.

How to use

1. Input

Paste or drop your content into the tool panel.
2. Process

Click the button. All processing is local in your browser.
3. Copy / Download

Copy the result or download to disk in one click.

How MongoDB ObjectId Generator & Decoder fits into your work

Use it in the small gaps between coding, reviewing, debugging, and shipping.

Developer jobs

Formatting, validating, shrinking, or inspecting code-adjacent text.
Preparing snippets for documentation, tickets, commits, or handoff.
Checking a small payload quickly without switching tools.

Developer checks

Run irreversible transforms like minify or obfuscate on a copy.
Keep secrets out of pasted snippets unless the tool explicitly stays local.
Use your normal tests or linter before shipping transformed code.

Good next steps

These links move the current task into a more complete workflow.

Real-world use cases

Debug a document by reading its insertion time
You pull a record out of a collection and want to know when it was created, but there is no createdAt field. Paste the _id into the decoder and you get the exact second the document was inserted, in UTC and your local time. No extra query, no schema change — the clock was in the primary key the whole time.
Backfill or migrate documents in a time window
A migration script needs every document created on a given day. Build the lowest ObjectId for the start of that day and the highest for the end, then query _id between those bounds. Because _id is already indexed the scan is fast, and you avoid adding a temporary createdAt index just to slice by time.
Generate stable ObjectIds for test fixtures
Your integration tests need a handful of realistic _id values that look like the real thing and sort in a predictable order. Generate a batch, copy them into your seed file, and the counter increment keeps them strictly ascending so any "order by _id" assertion stays stable across runs.
Explain ObjectId structure to a teammate
Onboarding someone who has only seen auto-increment integer keys? Generate one ObjectId, decode it, and walk through the timestamp, random and counter bytes live. The shareable URL reopens the exact id and decoded view, so you can drop it into a chat message and have them see what you see.

Common pitfalls

Treating the ObjectId timestamp as milliseconds. The leading 4 bytes hold whole seconds, so the embedded time has one-second resolution. Two documents inserted 100 ms apart can carry the same ObjectId second; rely on the counter, not the time, to order them within that second.
Sorting by _id and expecting perfect chronological order across machines. The counter and random field only guarantee order within one process; ids from two servers in the same second can interleave. For strict cross-host time ordering keep a real timestamp field.
Building range-query bounds by hand and forgetting the trailing bytes. The low bound must zero the random and counter bytes and the high bound must max them out; using a bare 8-hex timestamp with random tail bytes will silently miss documents at the edges of the window.

Privacy

Every ObjectId is built and decoded by plain JavaScript inside your browser tab — the random bytes come from the local crypto API and no id, timestamp or query bound is ever sent to a server. There is no logging of what you generate or paste. The one caveat: the shareable URL encodes your settings and the ObjectId in the decoder into the query string, so a link pasted into chat records that id in the recipient server access log. If the id maps to a sensitive document, use the copy button and paste the text rather than sharing the URL.

FAQ

Tool combos

Folks in your role tend to reach for these alongside this tool.

Developer

Browse all tools for this role

MongoDB ObjectId Generator and Timestamp Decoder

What this tool does

Tool details

How to use

1. Input

2. Process

3. Copy / Download

How MongoDB ObjectId Generator & Decoder fits into your work

Developer jobs

Developer checks

Good next steps

Real-world use cases

Debug a document by reading its insertion time

Backfill or migrate documents in a time window

Generate stable ObjectIds for test fixtures

Explain ObjectId structure to a teammate

Common pitfalls

Privacy

FAQ

NanoID Generator

UUID Generator

ULID Generator

UUIDv7 Generator

Unix Timestamp Converter

AI Eval Planner

API Key Generator

ASCII Table Generator

ASCII Table Reference

awk + sed Cheatsheet

AWS CLI Cheatsheet

Backup Codes Generator