X (Twitter) Snowflake-ID-decoder

Inleiding

Elk bericht op X draagt een numerieke ID bij zich, en dat getal is niet willekeurig. Sinds november 2010 bouwt X tweet-ID's in het snowflake-formaat — een 64-bits geheel getal dat de exacte publicatietijd, de identiteit van de genererende machine en een volgteller in één sorteerbaar getal verpakt. De Toollect X (Twitter) Snowflake-ID-decoder pakt dat getal uit — plak een tweet-ID, 2089759704335482961, en je krijgt het precieze publicatiemoment, 18 augustus 2026 om 17:01:54.028 UTC, samen met het workernummer, het volgnummer en de volledige binaire opbouw van de ID.

In plaats daarvan een complete statuslink plakken werkt hetzelfde — de decoder haalt eerst de ID uit de URL, zodat https://x.com/jack/status/2089759704335482961 en het blote getal identieke resultaten geven. In beide gevallen verschijnen er acht resultaatrijen terwijl je typt — vier die beschrijven wanneer (lokale tijd, UTC, ISO 8601 en Unix-milliseconden, plus een compacte relatieve leeftijd) en drie die beschrijven wat de bits zeggen (worker-ID, volgnummer en de volledige 64-bits binaire vorm).

Het decoderen is pure bitrekenkunde, geen opslagwerk. Er wordt niets naar X gestuurd, geen API-sleutel nodig en er bestaat geen rate limit — de berekening draait al typend in je browser, en dezelfde ID decodeert overal ter wereld naar hetzelfde moment, voor altijd.

Gebruiksgevallen

Een getal dat heimelijk zijn eigen geboortetijd vastlegt blijkt in meer taken bruikbaar dan je zou verwachten.

Journalistiek en verificatie

Screenshots, reposts en citaten rukken een bericht los van zijn oorspronkelijke timing. Het decoderen van de ID herstelt die — de exacte milliseconde van creatie staat in het getal geschreven, los van wat de omringende pagina beweert. Factcheckers gebruiken dit om te bepalen of een bericht aan de gebeurtenis voorafgaat of erop volgt — de ID valt niet meer te bewerken, anders dan de tekst eromheen.

Data-analyse en archieven

ID's numeriek sorteren is berichten chronologisch sorteren — zonder dat er een tijdstempelkolom nodig is. Analisten die tweet-ID's exporteren uit API's of datasets gebruiken de decoder om die ID's aan kalenderdata te verankeren, verzamelflekken te vinden en archieven te dedupliceren waarin dezelfde tweet via meerdere URL-vormen aankwam maar altijd hetzelfde getal droeg.

Moderatie en onderzoek

Bij het doornemen van een activiteitsgolf geeft de relatieve rij meteen een gevoel van schaal — minuten oud tegen maanden oud — zonder dat tijdstempels hardop gelezen moeten worden. onderzoekers die verwijderpatronen of herplaatsingsgedrag bestuderen, decoderen ID-bereiken om tijdlijnen te reconstrueren die publiekelijk niet meer bestaan.

Ontwikkelaars en integraties

Code die tweet-ID's opslaat heeft tijdens de ontwikkeling vaak een gezondheidscontrole nodig — is deze constante echt een plausibele tweet-ID, en voor welk moment geeft hij zich uit? De waarde hier plakken antwoordt met één toetsaanslag, en de ISO-uitvoer kopiëren glipt direct in logs, fixtures of databaseseedjes.

Hoe het werkt

De tool werkt terwijl je typt — er is geen knop. Elke toetsaanslag doorloopt dezelfde vier stappen:

1. De invoer classificeren — de tekst wordt vergeleken met twee vormen — een blote snowflake van 15 tot 19 cijfers, of een x.com-/twitter.com-statuslink die er een draagt. Alles anders toont de melding voor ongeldige invoer.
2. De ID extraheren — vanuit een URL wordt alles behalve de statusroute en het getal genegeerd — subdomeinen, weergavevarianten zoals /photo/1 en queryparameters bereiken de berekening nooit.
3. De bits decoderen — BigInt-verschuivingen tillen de tijdstempel, worker en volgnummer uit het 64-bits getal, en de Twitter-epoch wordt opgeteld om de ruwe afstand in een echte datum te veranderen — de rekenkunde staat in het hoofdstuk Hoe de decodering werkt.
4. Het venster valideren — een ID waarvan de gedecodeerde tijd meer dan een minuut in de toekomst valt wordt geweigerd in plaats van getoond, zodat verkeerd getikte of verzonnen getallen luidruchtig falen in plaats van zelfverzekerd een onzinnige datum produceren.

Alles gebeurt lokaal in ruim onder een milliseconde. Het validatievenster is het enige oordeel in het proces, en het helt naar weigering — een getal dat beweert morgen gepost te zijn is geen tweet.

Ondersteunde invoerformaten

Twee families van invoer worden gedecodeerd, en alles anders wordt met een duidelijke melding geweigerd. Het contract is bewust smal — deze tool doet één ding met één soort getal.

Geaccepteerde formaten

Beide domeinen — x.com en twitter.com — gedragen zich identiek op elke hostvorm, het voorvoegsel https:// is optioneel, en afsluitende slashes, foto- of videovarianten en querystrings worden getolereerd en weggegooid. In welke gedaante het ook aankomt — de geëxtraheerde ID is dezelfde, dus de gedecodeerde uitvoer is bytegewijs identiek over alle zeven rijen van de tabel.

Geweigerde formaten

Twee weigeringen verdienen uitleg. De web-app-route x.com/i/web/status/… verschijnt wanneer de single-page-client adressen intern herschrijft, maar zij laat het segment met de gebruikersnaam weg en past dus niet in de grammatica hierboven — plak de canonieke vorm en dezelfde ID decodeert normaal. En kijk goed naar de laatste rij — een Discord-ID passeert de lengtecontrole en decodeert naar een plausibel ogende datum. De decoder kan hem niet herkennen, en die grens wordt eerlijk gedocumenteerd in plaats van verbloemd.

Anatomie van een Snowflake-ID

Een snowflake is een 64-bits geheel getal in vier velden gesneden. Gelezen vanaf de meest significante bit:

De epoch

Tijdstempels tellen niet vanaf 1970 — ze tellen vanaf 4 november 2010 om 01:42:54.657 UTC, het moment waarop de snowflake-dienst de sequentiële ID's verving. Een verse epoch kiezen houdt het tijdstempelveld klein — 41 bits bevatten zo'n 2.200 miljard milliseconden, ruim 69,7 jaar marge. Het formaat loopt daarom pas in juli 2080 leeg — comfortabel ver weg, en een van de redenen waarom het veld niet verbreed kan worden zonder alle bestaande clients te breken.

Een doorgerekend voorbeeld

Neem de ID die in de X-tools van deze site overal gebruikt wordt — 2089759704335482961. Op de veldgrenzen gesneden lees je in één oogopslag elke waarde af die de decoder print:

De voorloopnul in de tijdstempelrij is het altijd-nul-tekenbit. Elke uitvoerrij komt uit deze ene snede — de tijdstempelbits worden het publicatiemoment, het workerveld benoemt machine 376, en het volgnummer toont dat dit ID nummer 81 was dat die machine in die milliseconde sloeg.

Hoeveel ID's erin passen

De 12-bits volgteller staat tot 4.096 ID's per machine per milliseconde toe, en het 10-bits workerveld benoemt tot 1.024 machines. In de praktijk kruipt de volgteller zelden dicht bij zijn plafond — hij bestaat zodat bundels nooit botsen, niet voor het totaal. Twee ID's van dezelfde machine in dezelfde milliseconde verschillen alleen in die twaalf lage bits.

De cijfertijdlijn

Omdat de tijdstempel de hoge bits bezet, groeit de totale waarde gestaag — het aantal decimalen vertelt grofweg wanneer een ID geslagen werd:

Daarom accepteert de decoder 15 tot 19 cijfers en niets anders — 15 dekt de allereerste posts uit de snowflake-periode, 19 alles wat sinds 2018 geslagen is, en geen enkele legitieme tweet-ID viel ooit buiten die band.

Hoe de decodering werkt

De wiskunde zijn drie bewerkingen — een verschuiving, twee maskers en een optelling:

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

timestampMs = Number((id >> 22n) + TWEET_EPOCH);
workerId    = Number((id >> 12n) & 1023n);    // de lage 10 bits van het middelste veld
sequence    = Number(id & 4095n);             // de lage 12 bits

22 bits naar rechts verschuiven gooit de worker- en volgvelden weg en laat de tijdstempelafstand sinds de eigen epoch over; de epoch optellen maakt er gewone Unix-milliseconden van. De maskers isoleren daarna de twee lage velden — & 1023 houdt tien bits vast, & 4095 twaalf. Het voorbeeld nogmaals doorgerekend — 2089759704335482961 verschoven geeft een afstand van 498237539371 milliseconden, plus de epoch gelijk aan 1787072514028, dus 2026-08-18T17:01:54.028Z; de gemaskeerde worker is 376 en het volgnummer 81.

Twee precisiedetails tellen. Ten eerste doet de tool alle rekenkunde in BigInt, want een ID van 19 cijfers overstijgt het veilige gehele-getalbereik van JavaScript (9.007.199.254.740.991) en een gewoon getal zou stilzwijgend de lage bits afronden — precies de worker- en volgnummervelden waardoor precies de worker- en volgnummervelden die de tool rapporteert beschadigen. Ten tweede past de resulterende tijdstempel na conversie gemakkelijk in het veilige bereik, dus hem als gewoon getal aan Date geven verliest niets.

Nog iets wat de moeite van weten waard is — andere platforms snijden diezelfde 22 lage bits anders, en generieke decoders etiketteren ze vaak met de veldnamen van een ander systeem:

Als een tool je tweet-ID toont gesplitst in workerOrShard en processId, legt het Discords etiketten over de bits van X — de getallen laten zich berekenen, maar een tweet heeft geen procesveld, en de twaalf lage bits zijn een volgteller, geen procesidentificatie. Deze decoder blijft bij de velden die X echt definieert.

Gebruik

Vier stappen, geen knoppen:

1. Plak je invoer — een blote tweet-ID, of elke x.com-/twitter.com-statuslink in de hierboven genoemde vormen.
2. Lees de tijdgroep — lokale tijd, UTC, ISO 8601 en Unix-milliseconden vullen zich meteen, en de relatieve rij geeft de leeftijd in één blik.
3. Lees de anatomiegroep — worker-ID, volgnummer en de gegroepeerde binaire vorm tonen hoe het getal gebouwd is.
4. Kopieer wat je nodig hebt — elke rij heeft zijn eigen kopieerknop; de ISO-rij glipt netjes in spreadsheets en logs.

Ongeldige invoer veegt de rijen leeg en toont één foutregel; de invoer corrigeren wist de fout even automatisch.

Stapsgewijze handleiding

Loop één decoding van begin tot einde mee.

Stap 1 — Een blote ID decoderen. Plak 2089759704335482961 in de invoer. De tijdgroep vult zich onmiddellijk — ISO-rij 2026-08-18T17:01:54.028Z, Unix-rij 1787072514028 — en de anatomiegroep rapporteert worker 376, volgnummer 81, met het binair in zijn 42/10/12-groepen.

Stap 2 — Decoderen vanaf een complete link. Maak de invoer leeg en plak https://x.com/jack/status/2089759704335482961?s=20&t=abc. De trackingparameters veranderen niets — elke rij leest identiek aan stap 1, want alleen de statusroute en de ID overleven de extractie.

Stap 3 — Domeinonafhankelijkheid bevestigen. Plak https://www.twitter.com/someone/status/2089759704335482961/ — het oude domein met gebruikersnaamprefix en afsluitende slash. Dezelfde ID, dezelfde tijdstempel. Hoe de link je ook bereikte — het getal erin is de enige bron van waarheid.

Stap 4 — Een onmogelijke ID zien falen. Plak 20 — de ID van de eerste ooit gepubliceerde tweet, uit de periode vóór de snowflake. De decoder weigert hem — twee cijfers kunnen geen gecodeerde tijdstempel dragen, want die ID werd jaren vóór het formaat uitgegeven. De weigering is correct, geen bug.

Stap 5 — De uitvoer ergens nuttig maken. Klik op de kopieerknop van de ISO-rij en plak in een spreadsheetcel — 2026-08-18T17:01:54.028Z sorteert als tekst chronologisch, overleeft CSV-heen-en-weerretes en heeft geen tijzonecontext nodig om gelezen te worden.

Professionele tips

• Op ID sorteren is op tijd sorteren. Waar tweet-ID's ook in een kolom leven — exports, databases, logs — ordening op ID is chronologische ordening. De decoder helpt die ordening met echte data te etiketteren.
• Geef de ISO-rij de voorkeur voor opslag. Lokale tijd hangt af van de apparaatinstellingen van de lezer; ISO 8601 met het achtervoegsel Z is overal ondubbelzinnig en sorteert als platte tekst correct.
• UTC voor teams over tijzones heen. Wanneer een archief continenten beslaan, spreek de UTC-rij af en niemand discussieert erover of het bericht middernacht passeerde.
• Gebruik de relatieve rij voor triage. Bij het doornemen van een partij ID's scheidt de compacte leeftijd — 3h, 2d, 5mo — vers van oud sneller dan hele data lezen.
• De binaire rij is lesmateriaal. Iemand laten zien welke bits precies de tijdstempel zijn laat het hele formaat sneller klikken dan welk diagram dan ook.
• Paar hem met de URL-parser. De parser reinigt en canoniseert links; de decoder dateert ze. Laat dezelfde statuslink door beide gaan en je vertrekt met een nette URL en een geverifieerde tijdstempel.

Alternatieven

Op welke andere manieren kan een tweet-ID een datum worden?

Handmatig decoderen is machten van twee en lange binaire kettingen — een keer doenbaar, voor altijd vervelend, en één versprongen bit bederft de datum. Generieke online decoders mikken vaak eerst op Discord, etiketteren X-velden verkeerd en pakken soms de epoch mis, en ze sturen de ID meestal naar een server. Deze tool voert de exacte rekenkunde lokaal uit, etiketteert de velden zoals X ze definieert en weigert onmogelijke invoer in plaats van zelfverzekerd een fout jaartal te tonen.

Vergeleken met de officiële API's

Een aanmaaktijd lezen is de zeldzame taak waarin de officiële route strikt slechter is:

Sinds februari 2026 is de API van X betalen-per-gebruik zonder gratis tier — created_at halen voor zelfs maar één tweet kost geld en vereist geregistreerde inloggegevens. oEmbed levert gerenderde HTML voor insluiten, zonder gestructureerd tijdstempelveld dat betrouwbaar te parsen valt. De snowflake-rekenkunde levert dezelfde milliseconde gratis, offline en voor altijd — de prijs is dat hij niets onthult buiten het getal zelf, precies de grens die hieronder gedocumenteerd staat.

Decoder versus URL-parser

Toollect levert twee X-tools die beide statuslinks lezen en beide snowflake-ID's kennen. Ze beantwoorden verschillende vragen:

De parser is de generalist voor links; de decoder de specialist voor getallen. Dat hij complete URL's accepteert is een gemak — zodra een link schoonmaak, typwerk of uitleg vraagt, is dat parseterrein, en de twee tools geven het stokje netjes bij de ID door.

Wat de tool niet doet

De grenzen verdienen het genoemd te worden zodat de decoder nooit te veel vertrouwd wordt:

• Het haalt niets op. Nul verzoeken — de tool kan niet zien of de tweet nog bestaat, wie hem schreef of wat hij zegt. Uit de ID komt alleen wat er bij de geboorte ingebakken zat.
• Het kan de conversie niet omdraaien. Een datum terug naar een ID brengen fabriceert een getal dat geen enkele tweet ooit ontving — open x.com/i/status/{gefabriceerd} en X antwoordt dat de pagina niet bestaat. Synthetische ID's werkten uitsluitend als pagineringsdrempels in de oude gratis API; op het web van vandaag doen datumoperatoren dat werk direct.
• Het kan platforms niet uit elkaar houden. Een Discord-snowflake deelt de indeling en decodeert hier zonder foutmelding — naar een datum zo'n vier jaar te vroeg, omdat Discord sinds 2015 telt. Komt de invoer van een ander platform, behandel de uitvoer dan als bij constructie fout.
• Het decodeert geen ID's van vóór 2010. Tweets ouder dan de snowflake-dienst dragen kleine sequentiële nummers zonder ingebouwde klok — er is letterlijk niets te decoderen.
• Het gokt niet. Invoer die op geen enkele geaccepteerde vorm past toont de foutmelding in plaats van een partieel resultaat.

Probleemoplossing

Privacy en gegevensverwerking

Deze decoder opereert onder het strengste privacymodel van de site — hij maakt helemaal geen netwerkverzoeken.

• Er wordt niets geüpload. Decoderen is bitrekenkunde in je browser. De ID of link die je plakt bereikt nooit een server.
• Geen account, geen analytics, geen scripts van derden. De pagina draait alleen haar eigen code.
• Er wordt niets bewaard. Geen cookies, geen toestand tussen bezoeken — sluit het tabblad en de sessie is weg.

Voor workflows met ID's uit privéarchieven, onderzoeksdatasets of moderatiewachtrijen gebeurt de decoding volledig op jouw apparaat.

Technische specificaties

Details:

• Formaat — 64-bits snowflake — teken (1 bit) + tijdstempel (41 bits, ms sinds 2010-11-04T01:42:54.657Z) + worker (10 bits) + volgnummer (12 bits)
• Precisie — BigInt-rekenkunde door en door; resultaten exact voor alle 19-cijferige ID's buiten het veilige gehele-getalbereik van JavaScript
• Validatievenster — de gedecodeerde tijd mag de huidige tijd met hoogstens 60 seconden overstijgen; waarden vóór de epoch zijn vanaf 15 cijfers onbereikbaar
• Invoerformaten — blote \d{15,19}, of x.com-/twitter.com-status-URL's met optioneel protocol, www.-/mobile.-/m.-subdomeinen, weergavevarianten en querystrings
• Uitvoer — lokale tijd, UTC-tekenreeks, ISO 8601, Unix-milliseconden, relatieve leeftijd, worker-ID, volgnummer, gegroepeerde 64-bits binaire vorm — elke rij apart kopieerbaar
• Verwerking — 100% JavaScript aan de clientzijde, nul netwerkverzoeken, geen API-sleutel, geen serveronderdeel
• Browserondersteuning — alle moderne browsers (BigInt en Clipboard API)

Functies

• Decodeert elke X- of Twitter-snowflake-ID naar zijn exacte publicatiemoment, op de milliseconde nauwkeurig
• Accepteert losse tweet-ID's en complete x.com- of twitter.com-statuslinks — de ID wordt automatisch geëxtraheerd
• Toont het gedecodeerde moment op vier manieren — lokale tijd, UTC, ISO 8601 en Unix-milliseconden
• Splits de ID in zijn onderdelen — worker-ID, volgnummer en de volledige 64-bits binaire opbouw
• Weigert onmogelijke waarden — ID's met een toekomstige datum tonen een foutmelding in plaats van een gok
• Draait volledig in je browser zonder netwerkverzoeken — geen API-sleutel, geen account
• Kopiëren met één klik voor elke resultaatrij

Veelgestelde vragen