X (Twitter) Snowflake-ID-avkodare

Introduktion

Varje inlägg på X bär ett numeriskt ID, och talet är inte slumpmässigt. Sedan november 2010 bygger X tweet-ID:n i snowflake-format — ett 64-bitars heltal som packar den exakta publiceringstiden, den genererande maskinens identitet och en sekvensräknare i ett enda sorterbart tal. Toollects X (Twitter) Snowflake-ID-avkodare vecklar ut det talet — klistra in ett tweet-ID, 2089759704335482961, och du får den precisa publiceringstidpunkten, 18 augusti 2026 kl. 17:01:54.028 UTC, tillsammans med workernumret, sekvensen och ID:ts fullständiga binära uppbyggnad.

Att klistra in en hel statuslänk istället fungerar likadant — avkodaren extraherar först ID:t ur URL:en, så https://x.com/jack/status/2089759704335482961 och det nakna talet ger identiska resultat. I båda fallen dyker åtta resulterande rader upp allteftersom du skriver — fyra som beskriver när (lokal tid, UTC, ISO 8601 och Unix-millisekunder, plus en kompakt relativ ålder) och tre som beskriver vad bitarna säger (worker-ID, sekvens och den fullständiga 64-bitars binära formen).

Avkodningen är ren bitaritmetik, inte uppslagning. Ingenting skickas till X, ingen API-nyckel behövs och det finns ingen hastighetsgräns — beräkningen går i din webbläsare medan du skriver, och samma ID avkodas till samma ögonblick överallt i världen, för alltid.

Användningsområden

Ett tal som i smyg registrerar sin egen födelsedag visar sig vara användbart i fler jobb än man väntar sig.

Journalistik och verifiering

Skärmdumpar, reposts och citat lossar ett inlägg från sin ursprungliga tajming. Att avkoda ID:t återställer den — den exakta millisekunden då inlägget skapades står skrivet i talet, oberoende av vad sidan runt omkring påstår. Faktagranskare använder detta för att avgöra om ett inlägg föregår eller följer händelsen det handlar om — ID:t går inte att redigera efteråt, till skillnad från texten runtom.

Dataanalys och arkiv

Att sortera ID:n numeriskt är att sortera inlägg kronologiskt — helt utan tidsstämpelkolumn. Analytiker som exporterar tweet-ID:n från API:er eller datamängder använder avkodaren för att förankra ID:na vid kalenderdatum, upptäcka insamlingsglapp och deduplicera arkiv där samma tweet kom fram via flera URL-former men alltid bar samma tal.

Moderering och forskning

Vid genomgång av en aktivitetsvåg ger den relativa raden omedelbar känsla för skalan — minuter mot månader — utan att tidsstämplar läses högt. Forskare som studerar raderingsmönster eller vidarepubliceringsbeteende avkodar ID-intervall för att rekonstruera tidslinjer som inte längre finns offentligt.

Utvecklare och integrationer

Kod som lagrar tweet-ID:n behöver ofta en sundhetskontroll under utvecklingen — är denna konstant verkligen ett plausibelt tweet-ID, och vilken tidpunkt utger den sig för att vara? Att klistra in värdet här svarar med en tangenttryckning, och ISO-utdata kopieras rakt ner i loggar, fixtures eller databasfrön.

Så fungerar det

Verktyget arbetar medan du skriver — det finns ingen knapp. Varje tangenttryckning går igenom samma fyra steg:

1. Klassificera inmatningen — texten matchas mot två former — en naken snowflake med 15–19 siffror, eller en x.com-/twitter.com-statuslänk som bär en. Allt annat visar meddelandet om ogiltig inmatning.
2. Extrahera ID:t — från en URL ignoreras allt utom statusrutten och talet — underdomäner, visningsvarianter som /photo/1 och frågeparametrar når aldrig beräkningen.
3. Avkoda bitarna — BigInt-skiftningar drar ut tidsstämpeln, workern och sekvensen ur 64-bitars heltalet, och Twitter-epoken adderas för att göra om råoffseten till ett riktigt datum — aritmetiken står i kapitlet Hur avkodningen går till.
4. Validera fönstret — ett ID vars avkodade tid landar mer än en minut i framtiden avvisas istället för att visas, så att felskrivna eller påhittade tal misslyckas högljutt istället för att med självförtroende producera ett nonsensdatum.

Allt händer lokalt på väl under en millisekund. Valideringsfönstret är den enda bedömningen i flödet, och det lutar åt avslag — ett tal som påstår sig postat imorgon är ingen tweet.

Stödda inmatningsformat

Två familjer av inmatning avkodas, och allt annat avvisas med tydligt meddelande. Kontraktet är medvetet smalt — verktyget gör en sak åt en sorts tal.

Godkända format

Båda domänerna — x.com och twitter.com — beter sig identiskt på alla hostformer, prefixet https:// är valfritt, och avslutande snedstreck, foto- eller videovarianter samt frågesträngar tolereras och kastas bort. Vilken gestalt det än kommer i — det extraherade ID:t är samma, så den avkodade utdatan är byteidentisk över tabellens alla sju rader.

Avvisade format

Två avvisanden förtjänar förklaring. Webbappsrutten x.com/i/web/status/… dyker upp när single-page-klienten skriver om adresser internt, men den utelämnar segmentet med användarnamnet och passar därför inte grammatiken ovan — klistra in den kanoniska formen och samma ID avkodas normalt. Och titta noga på sista raden — ett Discord-ID klarar längdkontrollen och avkodas till ett plausibelt utseende datum. Avkodaren kan inte upptäcka det, och den gränsen dokumenteras ärligt istället för att putsas över.

Anatomin i ett snowflake-ID

En snowflake är ett 64-bitars heltal skuret i fyra fält. Läst från mest signifikanta bit:

Epoken

Tidsstämplar räknas inte från 1970 — de räknas från den 4 november 2010 kl. 01:42:54.657 UTC, ögonblicket då snowflake-tjänsten ersatte de sekventiella ID:na. En färsk epok håller tidsstämpelfältet litet — 41 bitar rymmer cirka 2 200 miljarder millisekunder, ungefär 69,7 års marginal. Formatet tar därför slut först i juli 2080 — behagligt långt bort, och en av anledningarna till att fältet inte kan breddas utan att krossa alla befintliga klienter.

Ett genomräknat exempel

Ta ID:t som används genomgående i X-verktygen på denna sajt — 2089759704335482961. Skuret vid fältgränserna läser man av varje värde avkodaren skriver ut:

Den inledande nollan i tidsstämpelraden är teckenbiten som alltid är noll. Varje utdatarad härrör från denna enda snitt — tidsstämpelbitarna blir publiceringsögonblicket, workerfältet namnger maskin 376, och sekvensen visar att detta var ID nummer 81 som den maskinen slog i den millisekunden.

Hur många ID:n som ryms

12-bitssekvensen tillåter upp till 4 096 ID:n per maskin per millisekund, och 10-bitsworkerfältet namnger upp till 1 024 maskiner. I praktiken kryper sekvensen sällan nära sitt tak — den finns till för att salvor aldrig ska krocka, inte för totalsumman. Två ID:n från samma maskin i samma millisekund skiljer sig bara i dessa tolv låga bitar.

Siffrornas tidslinje

Eftersom tidsstämpeln ockuperar de höga bitarna växer totalvärdet stadigt — antalet decimalsiffror säger ungefär när ett ID präglades:

Därför accepterar avkodaren 15 till 19 siffror och ingenting annat — 15 täcker de allra första inläggen från snowflake-eran, 19 allt som präglats sedan 2018, och inget legitimt tweet-ID har någonsin fallit utanför det intervallet.

Hur avkodningen går till

Matematiken är tre operationer — en skiftning, två masker och en addition:

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

timestampMs = Number((id >> 22n) + TWEET_EPOCH);
workerId    = Number((id >> 12n) & 1023n);    // de låga 10 bitarna av mittenfältet
sequence    = Number(id & 4095n);             // de låga 12 bitarna

Att skifta 22 bitar åt höger slänger worker- och sekvensfälten och lämnar tidsstämpeloffseten sedan den egna epoken; att addera epoken gör vanliga Unix-millisekunder av den. Maskerna isolerar därefter de två låga fälten — & 1023 behåller tio bitar, & 4095 tolv. Exemplet genomräknat på nytt — 2089759704335482961 skiftat ger en offset på 498237539371 millisekunder, vilket plus epoken blir 1787072514028, alltså 2026-08-18T17:01:54.028Z; den maskerade workern är 376 och sekvensen 81.

Två precisionsdetaljer spelar roll. För det första görs all aritmetik i BigInt, för ett ID på 19 siffror överskrider JavaScripts säkra heltalsintervall (9 007 199 254 740 991) och ett vanligt tal skulle tyst avrunda de låga bitarna — och korrumpera just de worker- och sekvensvärden verktyget rapporterar. För det andra ryms den resulterande tidsstämpeln efter konverteringen gott i det säkra intervallet, så att visa den som vanligt tal för Date förlorar ingenting.

Ytterligare något värt att veta — andra plattformar skär samma låga 22 bitar olika, och generiska avkodare etiketterar dem ofta med ett annat systems fältnamn:

Om ett verktyg visar ditt tweet-ID delat mellan workerOrShard och processId lägger det Discords etiketter över X:s bitar — talen låter sig beräknas, men en tweet har inget processfält, och de tolv låga bitarna är en sekvensräknare, ingen processidentifierare. Denna avkodare håller sig till fälten X faktiskt definierar.

Användning

Fyra steg, inga knappar:

1. Klistra in din inmatning — ett naket tweet-ID, eller vilken x.com-/twitter.com-statuslänk som helst i formerna listade ovan.
2. Läs tidsgruppen — lokal tid, UTC, ISO 8601 och Unix-millisekunder fylls på direkt, och den relativa raden ger åldern i en snabb blick.
3. Läs anatomigruppen — worker-ID, sekvens och den grupperade binära formen visar hur talet är byggt.
4. Kopiera det du behöver — varje rad har sin egen kopieringsknapp; ISO-raden glider rent ner i kalkylblad och loggar.

Ogiltig inmatning tömmer raderna och visar en enda felrad; att korrigera inmatningen raderar felet lika automatiskt.

Steg-för-steg-guide

Följ en avkodning från början till slut.

Steg 1 — Avkoda ett naket ID. Klistra in 2089759704335482961 i inmatningen. Tidsgruppen fylls omedelbart — ISO-rad 2026-08-18T17:01:54.028Z, Unix-rad 1787072514028 — och anatomigruppen rapporterar worker 376, sekvens 81, med det binära i sina 42/10/12-grupper.

Steg 2 — Avkoda från en hel länk. Töm inmatningen och klistra in https://x.com/jack/status/2089759704335482961?s=20&t=abc. Spårningsparametrarna ändrar ingenting — varje rad läses identisk med steg 1, för bara statusrutten och ID:t överlever extraktionen.

Steg 3 — Bekräfta domänoberoendet. Klistra in https://www.twitter.com/someone/status/2089759704335482961/ — den gamla domänen med användarnamnprefix och avslutande snedstreck. Samma ID, samma tidsstämpel. Hur länken än nådde dig är talet i den den enda sanningskällan.

Steg 4 — Se ett omöjligt ID misslyckas. Klistra in 20 — ID:t för den första tweet som någonsin postats, från eran före snowflake. Avkodaren avvisar den — två siffror kan inte bära en kodad tidsstämpel, eftersom det ID:t utfärdades år före formatet fanns. Avvisandet är korrekt, ingen bugg.

Steg 5 — Ta utdatan dit den gagnar. Klicka på kopieringsknappen på ISO-raden och klistra in i en kalkylbladscell — 2026-08-18T17:01:54.028Z sorteras kronologiskt som text, överlever CSV-resor fram och tillbaka och behöver ingen tidszonskontext för att läsas.

Proffstips

• Sortera efter ID så sorterar du efter tid. Var tweet-ID:n än bor i en kolumn — exporter, databaser, loggar — är ordning efter ID kronologisk ordning. Avkodaren hjälper dig att etikettera den ordningen med riktiga datum.
• Föredra ISO-raden för lagring. Lokal tid beror på läsarens enhetsinställningar; ISO 8601 med ändelsen Z är entydig överallt och sorteras korrekt som ren text.
• UTC för team över tidszoner. När ett arkiv spänner över kontinenter, kom överens om UTC-raden så bråkar ingen om huruvida inlägget passerade midnatt.
• Använd den relativa raden för triage. Vid genomgång av en hög med ID:n separerar den kompakta åldern — 3h, 2d, 5mo — färskt från gammalt snabbare än att läsa hela datum.
• Den binära raden är undervisningsmaterial. Att visa någon exakt vilka bitar som är tidsstämpeln får hela formatet att klicka snabbare än något diagram.
• Para ihop den med URL-parsern. Parsern städar och kanoniserar länkar; avkodaren daterar dem. Låt samma statuslänk gå genom båda och du lämnar med en prydlig URL och en verifierad tidsstämpel.

Alternativ

På vilket andra sätt kan ett tweet-ID bli ett datum?

Att avkoda manuellt är tvåpotenser och långa binära kedjor — görbart en gång, tröttsamt för alltid, och en halkad bit förstör datumet. Generiska onlineavkodare siktar ofta på Discord först, etiketterar X-fält fel och tar ibland fel epok, och de skickar vanligen ID:t till en server. Verktyget kör den exakta aritmetiken lokalt, etiketterar fälten som X definierar dem och avvisar omöjliga inmatningar istället för att visa ett felaktigt årtal med full självsäkerhet.

I jämförelse med de officiella API:erna

Att läsa en skapetid är det sällsynta fall där den officiella vägen är strikt sämre:

Sedan februari 2026 är X:s API betala-per-användning utan gratisnivå — att hämta created_at för ens en enda tweet kostar pengar och kräver registrerade inloggningsuppgifter. oEmbed returnerar renderad HTML för inbäddning, utan strukturerat tidsstämpelfält att tolka pålitligt. Snowflake-aritmetiken levererar samma millisekund gratis, offline och för alltid — priset är att den avslöjar ingenting bortom talet själv, just den gräns som dokumenteras nedan.

Avkodaren jämfört med URL-parsern

Toollect levererar två X-verktyg som båda läser statuslänkar och båda kan sina snowflake-ID:n. De svarar olika frågor:

Parsern är generalisten för länkar; avkodaren specialisten för tal. Att den accepterar hela URL:er är en bekvämlighet — i samma stund en länk kräver städning, skrivning eller förklaring är det parsterräng, och de två verktygen överlämnar stafettpinnen prydligt vid ID:t.

Vad verktyget inte gör

Gränserna förtjänar att nämnas så att avkodaren aldrig litas för mycket:

• Det hämtar ingenting. Noll anrop — verktyget kan inte se om tweeten fortfarande finns, vem som skrev den eller vad den säger. Ur ID:t kommer bara det som bakades in vid födseln.
• Det kan inte vända omvandlingen. Att föra tillbaka en tidpunkt till ett ID framställer ett tal som ingen tweet någonsin mottog — öppna x.com/i/status/{framställt} och X svarar att sidan inte finns. Syntetiska ID:n fungerade enbart som pagineringsgränser i det gamla gratis-API:t; på dagens webb gör datumoperatörerna det jobbet direkt.
• Det kan inte skilja plattformarna åt. En Discord-snowflake delar uppbyggnaden och avkodas här utan felmeddelande — till ett datum ungefär fyra år för tidigt, eftersom Discord räknar från 2015. Kommer inmatningen från annan plattform, betrakta utdatan som fel byggkonstruktion.
• Det avkodar inte ID:n före 2010. Tweets äldre än snowflake-tjänsten bär små sekventiella nummer utan inbyggd klocka — bokstavligt talat finns det inget att avkoda.
• Det gissar inte. En inmatning som matchar ingen godkänd form visar felmeddelandet istället för ett partiellt resultat.

Felsökning

Integritet och datahantering

Denna avkodare arbetar under sajtens striktaste integritetsmodell — den gör inga nätverksanrop alls.

• Ingenting laddas upp. Att avkoda är bitaritmetik i din webbläsare. ID:t eller länken du klistrar in når aldrig någon server.
• Inget konto, ingen analys, inga tredjepartsskript. Sidan kör bara sin egen kod.
• Ingenting sparas. Inga kakburkar, inget tillstånd mellan besök — stäng fliken och sessionen är borta.

För arbetsflöden med ID:n ur privata arkiv, forskningsdatauppsättningar eller moderationsköer sker avkodningen helt på din enhet.

Tekniska specifikationer

Detaljer:

• Format — 64-bitars snowflake — tecken (1 bit) + tidsstämpel (41 bitar, ms sedan 2010-11-04T01:42:54.657Z) + worker (10 bitar) + sekvens (12 bitar)
• Precision — BigInt-aritmetik genomgående; resultat exakta för alla 19-siffriga ID:n utanför JavaScripts säkra heltalsintervall
• Valideringsfönster — den avkodade tiden får overstiga nuvarande tid med högst 60 sekunder; värden före epoken är onåbara från 15 siffror
• Inmatningsformat — naket \d{15,19}, eller x.com-/twitter.com-status-URL:er med valfritt protokoll, www.-/mobile.-/m.-underdomäner, visningsvarianter och frågesträngar
• Utdata — lokal tid, UTC-sträng, ISO 8601, Unix-millisekunder, relativ ålder, worker-ID, sekvens, grupperad 64-bitars binär form — varje rad var för sig kopierbar
• Bearbetning — 100 % JavaScript på klientsidan, noll nätverksanrop, ingen API-nyckel, ingen serverkomponent
• Webbläsarstöd — alla moderna webbläsare (BigInt och Clipboard API)

Funktioner

• Avkodar vilken X- eller Twitter-snowflake-ID som helst till dess exakta publiceringsögonblick, på millisekundnivå
• Accepterar nakna tweet-ID:n och fullständiga x.com- eller twitter.com-statuslänkar — ID:t extraheras automatiskt
• Presenterar det avkodade ögonblicket på fyra sätt — lokal tid, UTC, ISO 8601 och Unix-millisekunder
• Delar ID:t i sina delar — worker-ID, sekvensräknare och den fullständiga 64-bitars binära uppbyggnaden
• Avvisar omöjliga värden — ID:n med framtidsdatum visar ett fel istället för en gissning
• Körs helt i din webbläsare utan nätverksanrop — ingen API-nyckel, inget konto
• Kopiera med ett klick för varje resulterande rad

Vanliga frågor