X (Twitter) Snowflake ID Decoder

Introduction

Every post on X carries a numeric ID, and the number is not random. Since November 2010, X has built tweet IDs in the snowflake format — a 64-bit integer that packs the exact posting time, the identity of the generating machine, and a sequence counter into one sortable number. The Toollect X (Twitter) Snowflake ID Decoder unwraps that number: paste a tweet ID — 2089759704335482961 — and it returns the precise posting moment, August 18, 2026 at 17:01:54.028 UTC, together with the ID's worker number, sequence count, and full binary layout.

Paste a full status link instead and the decoder extracts the ID from the URL first, so https://x.com/jack/status/2089759704335482961 and the bare number produce identical results. Either way, eight result rows appear as you type — four describing when (local time, UTC, ISO 8601, Unix milliseconds, plus a compact relative age) and three describing what the bits say (worker ID, sequence, and the complete 64-bit binary).

The decoding is pure bit arithmetic, not a lookup. Nothing is sent to X, no API key is needed, and no rate limit applies — the math runs in your browser as you type, and the same ID always decodes to the same instant anywhere in the world, forever.

Use Cases

A number that secretly records its own creation time turns out to be useful in more jobs than you might expect.

Journalism and verification

Screenshots, reposts, and quote-tweets all detach a post from its original timing. Decoding the ID restores it: the exact millisecond a post was created is written inside the number, independent of what the surrounding page claims. Fact-checkers use this to establish whether a post predates or postdates the event it discusses — the ID cannot be edited after the fact, unlike the text around it.

Data analysis and archives

Sorting IDs numerically is sorting posts chronologically — no timestamp column needed. Analysts who export tweet IDs from APIs or datasets use the decoder to anchor those IDs to calendar dates, spot collection gaps, and deduplicate archives where the same tweet arrived through several URL shapes but always carries the same number.

Moderation and research

When reviewing a burst of activity, the relative-time row gives an immediate sense of scale — minutes old versus months old — without reading timestamps aloud. Researchers studying deletion patterns or re-posting behaviour decode ID ranges to reconstruct timelines that no longer exist publicly.

Developers and integrations

Code that stores tweet IDs often needs a sanity check during development — is this constant actually a plausible tweet ID, and roughly when does it claim to be? Pasting the value here answers in one keystroke, and copying the ISO output drops straight into logs, fixtures, or database seeds.

How It Works

The decoder runs as you type — there is no button. Each keystroke walks the same four steps:

1. Classify the input — the text is matched against two shapes — a bare snowflake of 15 to 19 digits, or an x.com/twitter.com status link carrying one. Anything else shows the invalid-input message.
2. Extract the ID — from a URL, everything except the status route and the number is ignored: subdomains, view variants such as /photo/1, and query parameters never reach the math.
3. Decode the bits — BigInt shifts pull the timestamp, worker, and sequence out of the 64-bit integer, and the Twitter epoch is added to turn the raw offset into a real date (the arithmetic is laid out in How the Decoding Works).
4. Validate the window — an ID whose decoded time lands more than a minute in the future is rejected rather than shown, so fat-fingered or fabricated numbers fail loudly instead of producing a confident nonsense date.

Everything happens locally in well under a millisecond. The validation window is the only judgement call in the pipeline, and it errs toward refusal — a number that claims to be posted tomorrow is not a tweet.

Supported Input Formats

Two families of input decode, and everything else is refused with a clear message. The contract is deliberately narrow: this tool does one thing to one kind of number.

Accepted formats

Both domains — x.com and twitter.com — behave identically on every host form, the https:// prefix is optional, and trailing slashes, photo or video variants, and query strings are tolerated and discarded. Whatever shape arrives, the extracted ID is the same, so the decoded output is byte-for-byte identical across all seven rows of the table.

Rejected formats

Two rejections deserve explanation. The web-app route x.com/i/web/status/… appears when the single-page client rewrites addresses internally, but it omits the username segment, so it does not match the grammar above — paste the canonical form and the same ID decodes normally. And note the last row carefully — a Discord ID passes the length check and decodes to a plausible-looking date. The decoder cannot detect it, and that limit is documented honestly rather than papered over.

Anatomy of a Snowflake ID

A snowflake is a 64-bit integer sliced into four fields. Reading from the most significant bit:

The epoch

Timestamps do not count from 1970 — they count from November 4, 2010 at 01:42:54.657 UTC, the moment the snowflake service replaced sequential IDs. Choosing a fresh epoch keeps the timestamp field small: 41 bits hold about 2.2 trillion milliseconds, which is roughly 69.7 years of headroom. The format therefore runs dry in July 2080 — comfortably far away, and one reason the field cannot be widened without breaking every existing client.

A worked example

Take the ID used throughout the X tools on this site — 2089759704335482961. Slicing it on the field boundaries reads off every value the decoder prints:

The leading zero in the timestamp row is the ever-zero sign bit. Every output row is derived from this single split — the timestamp bits become the posting instant, the worker field names machine 376, and the sequence shows this was ID number 81 minted by that machine in that millisecond.

How many IDs fit

The 12-bit sequence allows up to 4,096 IDs per machine per millisecond, and the 10-bit worker field names up to 1,024 machines. In practice the sequence rarely climbs near its ceiling — it exists so that bursts, not totals, never collide. Two IDs from the same machine in the same millisecond differ only in these low twelve bits.

The digit-count timeline

Because the timestamp occupies the high bits, the total value grows steadily — which means the number of decimal digits tells you roughly when an ID was minted:

This is why the decoder accepts 15 to 19 digits and nothing else: 15 covers the very first snowflake-era posts, 19 covers everything minted since 2018, and no legitimate tweet ID has ever fallen outside that span.

How the Decoding Works

The math is three operations — a shift, two masks, and an addition:

const TWEET_EPOCH = 1288834974657n;           // 2010-11-04T01:42:54.657Z in Unix ms

timestampMs = Number((id >> 22n) + TWEET_EPOCH);
workerId    = Number((id >> 12n) & 1023n);    // low 10 bits of the middle field
sequence    = Number(id & 4095n);             // low 12 bits

Shifting right by 22 discards the worker and sequence fields, leaving the timestamp offset since the custom epoch; adding the epoch converts it to ordinary Unix milliseconds. The masks then isolate the two lower fields — & 1023 keeps ten bits, & 4095 keeps twelve. Walking the worked example again — 2089759704335482961 shifted yields an offset of 498237539371 milliseconds, which plus the epoch equals 1787072514028, i.e. 2026-08-18T17:01:54.028Z; the masked worker is 376 and the sequence 81.

Two precision details matter. First, the tool does all arithmetic in BigInt, because a 19-digit ID exceeds JavaScript's safe-integer range (9,007,199,254,740,991) and a plain number would silently round the low bits — corrupting exactly the worker and sequence values the tool reports. Second, once converted, the resulting timestamp fits easily inside the safe range, so rendering it as an ordinary number for Date is lossless.

One more thing worth knowing — other platforms slice the same low 22 bits differently, and generic decoders often label them with someone else's field names:

If a tool shows your tweet ID broken into workerOrShard and processId, it is applying Discord's labels to X's bits — the numbers compute, but a tweet has no process field, and the 12 low bits are a sequence counter, not a process identifier. This decoder sticks to the fields X actually defines.

Usage

Four steps, no buttons:

1. Paste your input — a bare tweet ID, or any x.com/twitter.com status link in the shapes listed above.
2. Read the time group — local time, UTC, ISO 8601, and Unix milliseconds fill instantly, with the relative row giving the age at a glance.
3. Read the anatomy group — worker ID, sequence, and the grouped binary show how the number is built.
4. Copy what you need — every row has its own copy button; the ISO row drops cleanly into spreadsheets and logs.

Invalid input clears the rows and shows a single error line; correcting the input clears the error just as automatically.

Tutorial

Walk one decode end to end.

Step 1 — Decode a bare ID. Paste 2089759704335482961 into the input. The time group fills immediately — ISO row 2026-08-18T17:01:54.028Z, Unix row 1787072514028 — and the anatomy group reports worker 376, sequence 81, with the binary split into its 42/10/12 groups.

Step 2 — Decode from a full link. Clear the input and paste https://x.com/jack/status/2089759704335482961?s=20&t=abc. The tracking parameters change nothing — every row reads identically to Step 1, because only the status route and the ID survive extraction.

Step 3 — Confirm domain independence. Paste https://www.twitter.com/someone/status/2089759704335482961/ — the old domain with a username prefix and trailing slash. Same ID, same timestamp. However the link reached you, the number inside it is the single source of truth.

Step 4 — Watch an impossible ID fail. Paste 20 — the ID of the first tweet ever posted, from the pre-snowflake era. The decoder rejects it: two digits cannot contain an encoded timestamp, because that ID was issued years before the format existed. The refusal is correct, not a bug.

Step 5 — Take the output somewhere useful. Click the copy button on the ISO row and paste into a spreadsheet cell — 2026-08-18T17:01:54.028Z sorts chronologically as text, survives CSV round-trips, and needs no timezone context to interpret.

Pro Tips

• Sort by ID to sort by time. Anywhere tweet IDs sit in a column — exports, databases, logs — ordering by the ID is ordering chronologically. The decoder helps you label that order with actual dates.
• Prefer the ISO row for storage. Local time depends on the reader's device settings; ISO 8601 with the Z suffix is unambiguous everywhere and sorts correctly as plain text.
• Use UTC for cross-timezone teams. When an archive spans continents, agree on the UTC row and nobody argues about whether the post crossed midnight.
• Glance at the relative row for triage. Reviewing a batch of IDs, the compact age — 3h, 2d, 5mo — separates fresh from ancient faster than reading full dates.
• The binary row is a teaching aid. Showing a colleague exactly which bits are the timestamp makes the whole format click faster than any diagram.
• Pair with the URL parser. The parser cleans and canonicalizes links; the decoder dates them. Run the same status link through both and you leave with a tidy URL and a verified timestamp.

Alternatives

How else can a tweet ID become a date?

Manual decoding means powers of two and long binary strings — workable once, tedious forever, and one slipped bit ruins the date. Generic online decoders frequently target Discord first, mislabeling X fields and sometimes getting epochs wrong, and they commonly POST the ID to a server. This tool runs the exact arithmetic locally, labels the fields as X defines them, and refuses impossible inputs instead of displaying a confident wrong year.

Against the Official APIs

Reading a creation time is the rare task where the official route is strictly worse:

Since February 2026, X's API has been pay-per-use with no free tier, so fetching created_at for even one tweet costs money and requires registered credentials. oEmbed returns rendered HTML for embedding, with no structured timestamp field to parse reliably. The snowflake arithmetic delivers the same millisecond for free, offline, and forever — the trade-off is that it reveals nothing beyond the number itself, which is precisely the boundary documented below.

Decoder vs. URL Parser

Toollect ships two X tools that both read status links and both know about snowflake IDs. They answer different questions:

The parser is the generalist for links; the decoder is the specialist for numbers. Its acceptance of full URLs is a convenience — the moment a link needs cleaning, typing, or explaining, that is parser territory, and the two tools hand off cleanly at the ID.

What It Doesn't Do

The limits are worth naming so the decoder is never over-trusted:

• It does not fetch anything. Zero requests — the tool cannot see whether the tweet still exists, who wrote it, or what it says. The ID yields only what was baked into it at birth.
• It cannot reverse the conversion. Turning a date back into an ID fabricates a number no tweet ever received — open x.com/i/status/{fabricated} and X answers that the page does not exist. Synthetic IDs worked solely as pagination thresholds in the old free API; on today's web, date-based search operators do that job directly.
• It cannot tell platforms apart. A Discord snowflake shares the layout and decodes here without error — to a date roughly four years too early, because Discord counts from 2015. If an input came from another platform, treat the output as wrong by construction.
• It does not decode pre-2010 IDs. Tweets older than the snowflake service carry small sequential numbers with no embedded clock — there is genuinely nothing to decode.
• It does not guess. An input matching neither accepted shape shows the error message rather than a partial result.

Troubleshooting

Privacy & Data Handling

This decoder operates under the strictest privacy model on the site — it makes no network requests at all.

• Nothing is uploaded. Decoding is bit arithmetic in your browser. The ID or link you paste never reaches any server.
• No account, no analytics, no third-party scripts. The page runs only its own code.
• Nothing is stored. No cookies, no local state between visits — close the tab and the session is gone.

For workflows involving IDs from private archives, research datasets, or moderation queues, the decoding happens entirely on your device.

Technical Specs

Details:

• Format — 64-bit snowflake — sign (1 bit) + timestamp (41 bits, ms since 2010-11-04T01:42:54.657Z) + worker (10 bits) + sequence (12 bits)
• Precision — BigInt arithmetic throughout; results exact for all 19-digit IDs beyond the JavaScript safe-integer range
• Validation window — decoded time must not exceed the current time by more than 60 seconds; earlier-than-epoch values are unreachable at 15+ digits
• Input formats — bare \d{15,19}, or x.com/twitter.com status URLs with optional protocol, www./mobile./m. subdomains, view variants, and query strings
• Output — local time, UTC string, ISO 8601, Unix milliseconds, relative age, worker ID, sequence, grouped 64-bit binary — each row individually copyable
• Processing — 100% client-side JavaScript, zero network requests, no API key, no server component
• Browser support — all modern browsers (BigInt and Clipboard API)

Features

• Decodes any X or Twitter snowflake ID into its exact posting time, down to the millisecond
• Accepts bare tweet IDs and full x.com or twitter.com status links — the ID is extracted automatically
• Presents the decoded moment four ways — local time, UTC, ISO 8601, and Unix milliseconds
• Splits the ID into its structural parts — worker ID, sequence counter, and the full 64-bit binary breakdown
• Rejects impossible values — IDs that fall in the future show an error instead of a guess
• Runs entirely in your browser with zero network requests — no API key, no account
• One-click copy for every result row

Frequently Asked Questions