X-Snowflake-ID-Dekodierer (Twitter)

Einleitung

Jeder Beitrag auf X trägt eine numerische ID, und diese Zahl ist nicht zufällig. Seit November 2010 baut X Tweet-IDs im Snowflake-Format — eine 64-Bit-Ganzzahl, die den exakten Veröffentlichungszeitpunkt, die Kennung der erzeugenden Maschine und einen Sequenzzähler in eine sortierbare Zahl packt. Der Toollect X-Snowflake-ID-Dekodierer wickelt diese Zahl aus: Fügen Sie eine Tweet-ID ein — 2089759704335482961 — und Sie erhalten den präzisen Veröffentlichungszeitpunkt, den 18. August 2026 um 17.01.54,028 UTC, zusammen mit Worker-Nummer, Sequenzwert und vollständiger Binärdarstellung der ID.

Stattdessen einen vollständigen Statuslink einzufügen funktioniert genauso — der Dekodierer extrahiert zuerst die ID aus der URL, sodass https://x.com/jack/status/2089759704335482961 und die nackte Zahl identische Ergebnisse liefern. In beiden Fällen erscheinen beim Tippen acht Ergebniszeilen — vier zur Frage wann (lokale Zeit, UTC, ISO 8601 und Unix-Millisekunden, dazu ein kompaktes Relatives-Alter) und drei dazu, was die Bits sagen (Worker-ID, Sequenz und die vollständige 64-Bit-Binärform).

Die Dekodierung ist reine Bitarithmetik, keine Nachschlag. Nichts wird an X gesendet, kein API-Schlüssel ist nötig, es gibt kein Ratenlimit — die Rechnung läuft bereits beim Tippen in Ihrem Browser, und dieselbe ID dekodiert überall auf der Welt und für immer zu derselben Sekunde.

Anwendungsfälle

Eine Zahl, die heimlich ihren eigenen Entstehungszeitpunkt aufzeichnet, erweist sich in mehr Aufgaben als nützlich, als man denkt.

Journalismus und Faktencheck

Screenshots, Reposts und Zitat-Tweets reißen einen Beitrag von seinem ursprünglichen Timing los. Die Dekodierung der ID stellt es wieder her — die exakte Millisekunde der Erstellung steht in der Zahl, unabhängig davon, was die Umgebung behauptet. Fact-Checker nutzen das, um zu bestimmen, ob ein Beitrag dem Ereignis zeitlich vorausgeht oder nachfolgt — die ID lässt sich nachträglich nicht bearbeiten, anders als der Text darum herum.

Datenanalyse und Archive

IDs numerisch zu sortieren heißt, Beiträge chronologisch zu sortieren — ganz ohne Zeitstempelspalte. Analysten, die Tweet-IDs aus APIs oder Datensätzen exportieren, nutzen den Dekodierer, um diese IDs an Kalenderdaten zu verankern, Sammellücken zu finden und Archive zu deduplizieren, in denen derselbe Tweet über mehrere URL-Formen ankam aber stets dieselbe Zahl trug.

Moderation und Forschung

Beim Durchsehen einer Aktivitätswelle gibt die Relative-Zeile sofort ein Gefühl für die Größenordnung — Minuten alt gegen Monate alt — ohne dass Zeitstempel laut gelesen werden müssten. Forscher, die Löschmuster oder Weiterverbreitungsverhalten untersuchen, dekodieren ID-Bereiche, um Zeitlinien zu rekonstruieren, die öffentlich nicht mehr existieren.

Entwickler und Integrationen

Code, der Tweet-IDs speichert, braucht während der Entwicklung oft einen Plausibilitätscheck — ist diese Konstante wirklich eine plausible Tweet-ID, und für welchen Zeitpunkt gibt sie sich aus? Das Einfügen des Werts hier antwortet mit einem Tastendruck, und das Kopieren der ISO-Ausgabe fällt direkt in Logs, Testfixtures oder Datenbank-Seeds.

So funktioniert es

Der Dekodierer läuft während der Eingabe — es gibt keinen Knopf. Jeder Tastenschlag durchläuft dieselben vier Schritte:

1. Eingabe klassifizieren — der Text wird gegen zwei Formen gematcht — eine nackte Snowflake mit 15 bis 19 Ziffern oder einen x.com-/twitter.com-Statuslink, der eine trägt. Alles andere zeigt die Fehlermeldung für ungültige Eingaben.
2. ID extrahieren — aus einer URL wird alles außer der Status-Route und der Zahl ignoriert — Subdomains, Ansichtvarianten wie /photo/1 und Abfrageparameter erreichen die Rechnung nie.
3. Bits dekodieren — BigInt-Verschiebungen ziehen Zeitstempel, Worker und Sequenz aus der 64-Bit-Ganzzahl, und die Twitter-Epoche wird addiert, um den Rohoffset in ein echtes Datum zu verwandeln (die Arithmetik steht im Abschnitt Wie die Dekodierung funktioniert).
4. Fenster prüfen — eine ID, deren dekodierte Zeit mehr als eine Minute in der Zukunft läge, wird abgelehnt statt angezeigt, sodass vertippte oder erdachte Zahlen laut scheitern statt ein selbstbewusstes Nonsens-Datum zu produzieren.

Alles geschieht lokal in deutlich unter einer Millisekunde. Das Validierungsfenster ist die einzige Beurteilung im Ablauf, und es neigt zur Ablehnung — eine Zahl, die von morgen postet, ist kein Tweet.

Unterstützte Eingabeformate

Zwei Familien von Eingaben werden dekodiert, alles andere wird mit klarer Meldung abgelehnt. Der Vertrag ist bewusst eng — dieses Tool tut eine Sache mit einer Art von Zahl.

Akzeptierte Formate

Beide Domains — x.com und twitter.com — verhalten sich auf jeder Hostform identisch, das Präfix https:// ist optional, und abschließende Schrägstriche, Foto- oder Videovarianten sowie Abfragestrings werden toleriert und verworfen. Welche Gestalt auch ankommt — die extrahierte ID ist dieselbe, und die dekodierte Ausgabe ist über alle sieben Zeilen der Tabelle hinweg byteidentisch.

Abgelehnte Formate

Zwei Ablehnungen verdienen eine Erklärung. Die Web-App-Route x.com/i/web/status/… erscheint, wenn der Single-Page-Client Adressen intern umschreibt, aber sie lässt das Benutzernamensegment weg und passt daher nicht zur Grammatik oben — fügen Sie die kanonische Form ein, und dieselbe ID dekodiert normal. Und beachten Sie die letzte Zeile genau — eine Discord-ID besteht den Längencheck und dekodiert zu einem plausibel aussehenden Datum. Der Dekodierer kann sie nicht erkennen, und diese Grenze wird ehrlich dokumentiert statt schöngeredet.

Anatomie einer Snowflake-ID

Eine Snowflake ist eine 64-Bit-Ganzzahl, in vier Felder geschnitten. Gelesen vom höchstwertigen Bit:

Die Epoche

Zeitstempel zählen nicht ab 1970 — sie zählen ab dem 4. November 2010 um 01.42.54,657 UTC, dem Moment, in dem der Snowflake-Dienst die sequenziellen IDs ablöste. Eine frische Epoche hält das Zeitstempelfeld klein — 41 Bit fassen etwa 2,2 Billionen Millisekunden, rund 69,7 Jahre Spielraum. Das Format läuft daher erst im Juli 2080 leer — angenehm fern, und einer der Gründe, warum das Feld nicht verbreitert werden kann, ohne jeden bestehenden Client zu brechen.

Ein durchgerechnetes Beispiel

Nehmen wir die ID, die in den X-Werkzeugen dieser Website durchgängig benutzt wird — 2089759704335482961. Auf den Feldgrenzen aufgeschnitten liest man jeden Wert ab, den der Dekodierer ausgibt:

Die führende Null in der Zeitstempelzeile ist das stets Nullbleibende Vorzeichenbit. Jede Ausgabezeile stammt aus dieser einen Aufteilung — die Zeitstempel-Bits werden zum Veröffentlichungszeitpunkt, das Worker-Feld benennt Maschine 376, und die Sequenz zeigt, dass dies die ID Nummer 81 war, die diese Maschine in dieser Millisekunde vergab.

Wie viele IDs hineinpassen

Die 12-Bit-Sequenz erlaubt bis zu 4.096 IDs pro Maschine und Millisekunde, und das 10-Bit-Worker-Feld benennt bis zu 1.024 Maschinen. In der Praxis klettert die Sequenz selten nahe an ihr Limit — sie existiert, damit nie kollidiert, was Schwall heißt, nicht Gesamtmenge. Zwei IDs derselben Maschine in derselben Millisekunde unterscheiden sich nur in diesen unteren zwölf Bits.

Die Stellenzahl-Chronologie

Weil der Zeitstempel die hohen Bits besetzt, wächst der Gesamtwert stetig — die Anzahl der Dezimalstellen verrät also ungefähr, wann eine ID geprägt wurde:

Deshalb akzeptiert der Dekodierer 15 bis 19 Ziffern und nichts anderes — 15 deckt die allerersten Posts der Snowflake-Ära ab, 19 alles seit 2018 Geprägte, und keine legitime Tweet-ID lag jemals außerhalb dieser Spanne.

Wie die Dekodierung funktioniert

Die Mathematik besteht aus drei Operationen — einer Verschiebung, zwei Masken und einer 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);    // niedrige 10 Bits des mittleren Felds
sequence    = Number(id & 4095n);             // niedrige 12 Bits

Um 22 Bits nach rechts verschoben, fallen Worker- und Sequenzfeld weg und übrig bleibt der Zeitstempel-Offset seit der eigenen Epoche; die Addition der Epoche macht daraus gewöhnliche Unix-Millisekunden. Die Masken isolieren danach die beiden unteren Felder — & 1023 behält zehn Bits, & 4095 zwölf. Beim Durchrechnen des Beispiels ergibt 2089759704335482961 verschoben einen Offset von 498237539371 Millisekunden, plus die Epoche gleich 1787072514028, also 2026-08-18T17:01:54.028Z; die maskierte Worker-ID ist 376, die Sequenz 81.

Zwei Genauigkeitsdetails sind wichtig. Erstens rechnet das Tool durchweg in BigInt, denn eine 19-stellige ID übersteigt den sicheren Ganzzahlbereich von JavaScript (9.007.199.254.740.991), und eine gewöhnliche Zahl würde still die unteren Bits runden — wodurch genau die Worker- und Sequenzwerte korrumpierten, die das Tool meldet. Zweitens passt der resultierende Zeitstempel nach der Umwandlung bequem in den sicheren Bereich, sodass die Ausgabe als gewöhnliche Zahl für Date verlustfrei ist.

Noch etwas Wissenswertes — andere Plattformen schneiden dieselben niedrigen 22 Bits unterschiedlich, und generische Dekodierer beschriften sie oft mit den Feldnamen eines fremden Systems:

Zeigt Ihnen ein Tool Ihre Tweet-ID zerlegt in workerOrShard und processId, legt es Discords Beschriftungen über Xs Bits — die Zahlen lassen sich berechnen, aber ein Tweet hat kein Prozessfeld, und die zwölf unteren Bits sind ein Sequenzzähler, keine Prozesskennung. Dieser Dekodierer bleibt bei den Feldern, die X tatsächlich definiert.

Verwendung

Vier Schritte, keine Knöpfe:

1. Eingabe einfügen — eine nackte Tweet-ID oder einen x.com-/twitter.com-Statuslink in den oben gelisteten Formen.
2. Zeitgruppe lesen — lokale Zeit, UTC, ISO 8601 und Unix-Millisekunden füllen sich sofort, die Relative-Zeile gibt das Alter auf einen Blick.
3. Anatomiegruppe lesen — Worker-ID, Sequenz und die gruppierte Binärform zeigen, wie die Zahl gebaut ist.
4. Kopieren, was Sie brauchen — jede Zeile hat ihren eigenen Kopierknopf; die ISO-Zeile landet sauber in Tabellen und Logs.

Ungültige Eingabe leert die Zeilen und zeigt eine einzige Fehlerzeile; korrigierte Eingabe löscht den Fehler ebenso automatisch.

Tutorial

Begleiten Sie eine Dekodierung von Anfang bis Ende.

Schritt 1 — Eine nackte ID dekodieren. Fügen Sie 2089759704335482961 in die Eingabe ein. Die Zeitgruppe füllt sich sofort — ISO-Zeile 2026-08-18T17:01:54.028Z, Unix-Zeile 1787072514028 — und die Anatomiegruppe meldet Worker 376, Sequenz 81, mit der Binärform in ihren 42/10/12-Gruppen.

Schritt 2 — Aus einem vollständigen Link dekodieren. Leeren Sie die Eingabe und fügen Sie https://x.com/jack/status/2089759704335482961?s=20&t=abc ein. Die Tracking-Parameter ändern nichts — jede Zeile liest sich identisch zu Schritt 1, weil nur die Status-Route und die ID die Extraktion überstehen.

Schritt 3 — Domainunabhängigkeit bestätigen. Fügen Sie https://www.twitter.com/someone/status/2089759704335482961/ ein — die alte Domain mit Benutzernamen-Präfix und abschließendem Schrägstrich. Dieselbe ID, derselbe Zeitstempel. Wie auch immer der Link Sie erreichte — die Zahl darin ist die einzige Wahrheitsquelle.

Schritt 4 — Eine unmögliche ID scheitern sehen. Fügen Sie 20 ein — die ID des ersten je geposteten Tweets aus der Zeit vor dem Snowflake-Format. Der Dekodierer lehnt sie ab — zwei Ziffern können keinen kodierten Zeitstempel tragen, weil diese ID Jahre vor dem Format vergeben wurde. Die Ablehnung ist korrekt, kein Fehler.

Schritt 5 — Die Ausgabe dorthin bringen, wo sie nützt. Klicken Sie auf den Kopierknopf der ISO-Zeile und fügen Sie in eine Tabellenzelle ein — 2026-08-18T17:01:54.028Z sortiert als Text chronologisch, übersteht CSV-Rundreisen und braucht keinen Zeitzonenkontext, um gelesen zu werden.

Tipps für Profis

• Nach ID sortieren heißt nach Zeit sortieren. Überall, wo Tweet-IDs in einer Spalte sitzen — Exporte, Datenbanken, Logs — bedeutet Ordnung nach ID chronologische Ordnung. Der Dekodierer hilft, diese Ordnung mit echten Daten zu etikettieren.
• Für die Ablage die ISO-Zeile bevorzugen. Lokale Zeit hängt von den Geräteeinstellungen des Lesers ab; ISO 8601 mit dem Suffix Z ist überall eindeutig und sortiert sich als Klartext korrekt.
• UTC für teams über Zeitzonen hinweg. Wenn ein Archiv Kontinente überspannt, einigen Sie sich auf die UTC-Zeile, und niemand streitet darüber, ob der Beitrag Mitternacht gekreuzt hat.
• Die Relative-Zeile für die Sichtung nutzen. Beim Durchsehen eines Stapels von IDs trennt das kompakte Alter — 3h, 2d, 5mo — Frisches von Altem schneller als ganze Daten gelesen.
• Die Binärzeile ist ein Lehrmittel. Einer Kollegin zu zeigen, welche Bits genau der Zeitstempel sind, bringt das ganze Format schneller zum Klicken als jedes Diagramm.
• Mit dem URL-Parser paaren. Der Parser reinigt und kanonisiert Links; der Dekodierer datiert sie. Denselben Statuslink durch beide laufen lassen, und Sie verlassen die Seite mit ordentlicher URL und geprüftem Zeitstempel.

Alternativen

Wie sonst wird eine Tweet-ID zu einem Datum?

Manuelles Dekodieren heißt Zweierpotenzen und lange Binärketten — einmal machbar, für immer mühsam, und ein verrutschtes Bit verdirbt das Datum. Generische Online-Dekodierer zielen häufig zuerst auf Discord, beschriften X-Felder falsch und treffen manchmal die Epoche nicht, und sie senden die ID oft an einen Server. Dieses Tool rechnet exakt lokal, beschriftet die Felder so, wie X sie definiert, und lehnt unmögliche Eingaben ab, statt ein selbstbewusst falsches Jahr anzuzeigen.

Gegen die offiziellen APIs

Das Lesen einer Erstellungszeit ist der seltene Fall, in dem der offizielle Weg strikt schlechter ist:

Seit Februar 2026 ist Xs API Pay-per-use ohne kostenlosen Tarif — das Abrufen von created_at für auch nur einen Tweet kostet Geld und erfordert registrierte Zugangsdaten. oEmbed liefert gerendertes HTML zum Einbetten, ohne strukturiertes Zeitstempelfeld, das man zuverlässig parsen könnte. Die Snowflake-Arithmetik liefert dieselbe Millisekunde gratis, offline und für immer — der Preis ist, dass sie nichts über die Zahl hinaus verrät, genau die Grenze, die unten dokumentiert ist.

Dekodierer gegen URL-Parser

Toollect liefert zwei X-Werkzeuge, die beide Statuslinks lesen und beide Snowflake-IDs kennen. Sie beantworten verschiedene Fragen:

Der Parser ist der Generalist für Links; der Dekodierer der Spezialist für Zahlen. Dass er auch volle URLs annimmt, ist ein Komfort — sobald ein Link gereinigt, getippt oder erklärt werden will, ist das Parser-Gebiet, und die beiden Werkzeuge reichen sich sauber an der ID weiter.

Was dieses Tool nicht tut

Die Grenzen sind es wert, genannt zu werden, damit der Dekodierer nie übertrieben vertraut wird:

• Es ruft nichts ab. Null Anfragen — das Tool kann nicht sehen, ob der Tweet noch existiert, wer ihn schrieb oder was er sagt. Die ID gibt nur her, was bei ihrer Geburt hineingebacken wurde.
• Es kann die Umkehrung nicht. Aus einem Datum zurück in eine ID entsteht eine fabrizierte Zahl, die kein Tweet je erhalten hat — der Aufruf von x.com/i/status/{fabriziert} beantwortet X mit der Meldung, die Seite existiere nicht. Synthetische IDs funktionierten allein als Paginierungsgrenzen der alten Gratis-API; im heutigen Web erledigen datumsbasierte Suchoperatoren diese Aufgabe direkt.
• Es kann Plattformen nicht auseinanderhalten. Eine Discord-Snowflake teilt das Layout und dekodiert hier fehlerfrei — auf ein Datum rund vier Jahre zu früh, weil Discord ab 2015 zählt. Stammt eine Eingabe von einer anderen Plattform, betrachten Sie die Ausgabe als von Grund auf falsch.
• Es dekodiert keine IDs vor 2010. Tweets, die älter sind als der Snowflake-Dienst, tragen kleine sequenzielle Nummern ohne eingebettete Uhr — da gibt es buchstäblich nichts zu dekodieren.
• Es rät nicht. Eine Eingabe, die keiner akzeptierten Form entspricht, zeigt die Fehlermeldung statt eines Teilresultats.

Fehlerbehebung

Datenschutz & Datenhandlung

Dieser Dekodierer arbeitet unter dem strengsten Datenschutzmodell der Website — er stellt überhaupt keine Netzwerkanfragen.

• Nichts wird hochgeladen. Dekodieren ist Bitarithmetik in Ihrem Browser. Die ID oder der Link, die Sie einfügen, erreichen nie irgendeinen Server.
• Kein Konto, keine Analytik, keine Drittanbieter-Skripte. Die Seite führt nur ihren eigenen Code aus.
• Nichts wird gespeichert. Keine Cookies, kein Zustand zwischen Besuchen — den Tab schließen und die Sitzung ist vorbei.

Für Arbeitsabläufe mit IDs aus privaten Archiven, Forschungsdatensätzen oder Moderationswarteschlangen geschieht die Dekodierung vollständig auf Ihrem Gerät.

Technische Daten

Einzelheiten:

• Format — 64-Bit-Snowflake — Vorzeichen (1 Bit) + Zeitstempel (41 Bits, ms seit 2010-11-04T01:42:54,657Z) + Worker (10 Bits) + Sequenz (12 Bits)
• Präzision — durchweg BigInt-Arithmetik; Ergebnisse exakt für alle 19-stelligen IDs jenseits des sicheren Ganzzahlbereichs von JavaScript
• Validierungsfenster — dekodierte Zeit darf die aktuelle Zeit um höchstens 60 Sekunden überschreiten; vor der Epoche liegende Werte sind ab 15 Stellen unerreichbar
• Eingabeformate — nackte \d{15,19} oder x.com-/twitter.com-Status-URLs mit optionalem Protokoll, www.-/mobile.-/m.-Subdomains, Ansichtvarianten und Querystrings
• Ausgabe — lokale Zeit, UTC-Zeichenkette, ISO 8601, Unix-Millisekunden, relatives Alter, Worker-ID, Sequenz, gruppierte 64-Bit-Binärform — jede Zeile einzeln kopierbar
• Verarbeitung — 100 % clientseitiges JavaScript, null Netzwerkanfragen, kein API-Schlüssel, keine Serverkomponente
• Browserunterstützung — alle modernen Browser (BigInt und Clipboard-API)

Funktionen

• Dekodiert jede X- oder Twitter-Snowflake-ID in ihre exakte Veröffentlichungszeit auf die Millisekunde genau
• Akzeptiert nackte Tweet-IDs und vollständige x.com- oder twitter.com-Statuslinks — die ID wird automatisch extrahiert
• Zeigt den dekodierten Moment auf vier Arten — lokale Zeit, UTC, ISO 8601 und Unix-Millisekunden
• Zerlegt die ID in ihre Bestandteile — Worker-ID, Sequenzzähler und die vollständige 64-Bit-Binärdarstellung
• Verwirft unmögliche Werte — IDs, die in der Zukunft liegen, erzeugen eine Fehlermeldung statt einer Schätzung
• Läuft vollständig im Browser ohne Netzwerkanfragen — kein API-Schlüssel, kein Konto
• Ein-Klick-Kopieren für jede Ergebniszeile

Häufig gestellte Fragen