X (Twitter) Décodeur de Snowflake ID

Introduction

Chaque publication sur X porte un ID numérique, et ce nombre n'est rien de aléatoire. Depuis novembre 2010, X construit les IDs de tweets au format snowflake — un entier 64 bits qui empaquète l'heure exacte de publication, l'identité de la machine génératrice et un compteur de séquence en un seul nombre triable. Le X (Twitter) Décodeur de Snowflake ID de Toollect déballe ce nombre — collez un ID de tweet, 2089759704335482961, et il renvoie l'instant précis de publication, le 18 août 2026 à 17:01:54,028 UTC, avec le numéro de worker, la séquence et la structure binaire complète de l'ID.

Coller à la place un lien de statut complet fonctionne pareil — le décodeur extrait d'abord l'ID de l'URL, de sorte que https://x.com/jack/status/2089759704335482961 et le nombre nu produisent des résultats identiques. Dans les deux cas, huit lignes de résultats apparaissent pendant que vous tapez — quatre qui décrivent quand (heure locale, UTC, ISO 8601 et millisecondes Unix, plus un âge relatif compact) et trois qui décrivent ce que disent les bits (worker ID, séquence et le binaire complet sur 64 bits).

Le décodage est une arithmétique de bits pure, pas une consultation. Rien n'est envoyé à X, aucune clé API n'est nécessaire et il n'existe aucune limite de requêtes — le calcul tourne dans votre navigateur pendant que vous tapez, et le même ID se décode au même instant partout dans le monde, pour toujours.

Cas d'usage

Un nombre qui enregistre en secret sa propre heure de naissance se révèle utile dans davantage de travaux qu'on ne le croirait.

Journalisme et vérification

Les captures d'écran, les reposts et les citations détachent une publication de son rythme d'origine. Décoder l'ID le restaure — la milliseconde exacte de création est écrite dans le nombre, indépendamment de ce que prétend la page environnante. Les vérificateurs de faits s'en servent pour établir si une publication précède ou suit l'événement dont elle parle — l'ID ne peut pas être modifié après coup, contrairement au texte autour.

Analyse de données et archives

Trier des IDs numériquement, c'est trier des publications chronologiquement — sans colonne d'horodatage nécessaire. Les analystes qui exportent des IDs de tweets depuis des APIs ou des jeux de données utilisent le décodeur pour ancrer ces IDs à des dates calendaires, repérer les trous de collecte et dédupliquer des archives où le même tweet est arrivé sous plusieurs formes d'URL mais portait toujours le même nombre.

Modération et recherche

En examinant une salve d'activité, la ligne relative donne un sens immédiat de l'échelle — minutes contre mois — sans lire les horodatages à voix haute. Les chercheurs qui étudient les schémas de suppression ou les comportements de republication décodent des plages d'IDs pour reconstituer des chronologies qui n'existent plus publiquement.

Développeurs et intégrations

Le code qui stocke des IDs de tweets a souvent besoin d'une vérification de bon sens pendant le développement — cette constante est-elle vraiment un ID plausible, et quel moment prétend-elle être ? Coller la valeur ici répond en une frappe, et copier la sortie ISO glisse directement dans les logs, les fixtures ou les amorces de base de données.

Comment ça fonctionne

L'outil travaille pendant que vous tapez — il n'y a aucun bouton. Chaque touche parcourt les mêmes quatre étapes :

1. Classifier l'entrée — le texte est comparé à deux formes — un snowflake nu de 15 à 19 chiffres ou un lien de statut x.com/twitter.com qui en porte un. Tout le reste affiche le message d'entrée invalide.
2. Extraire l'ID — depuis une URL, tout sauf la route de statut et le nombre est ignoré — sous-domaines, variantes de vue telles que /photo/1 et paramètres de requête n'atteignent jamais le calcul.
3. Décoder les bits — des décalages BigInt tirent l'horodatage, le worker et la séquence de l'entier 64 bits, et l'époque Twitter est ajoutée pour convertir le décalage brut en vraie date — l'arithmétique est posée dans le chapitre Comment fonctionne le décodage.
4. Valider la fenêtre — un ID dont l'heure décodée atterrirait à plus d'une minute dans le futur est rejeté plutôt qu'affiché, afin que les nombres mal tapés ou inventés échouent bruyamment au lieu de produire une date absurde en toute assurance.

Tout se passe localement en bien moins d'une milliseconde. La fenêtre de validation est le seul jugement du pipeline, et elle penche vers le refus — un nombre qui prétend être publié demain n'est pas un tweet.

Formats d'entrée pris en charge

Deux familles d'entrées se décodent, et tout le reste est refusé avec un message clair. Le contrat est délibérément étroit — cet outil fait une seule chose à un seul genre de nombre.

Formats acceptés

Les deux domaines — x.com et twitter.com — se comportent identiquement sur toutes les formes d'hôte, le préfixe https:// est facultatif, et les barres obliques finales, les variantes photo ou vidéo ainsi que les chaînes de requête sont tolérés puis jetés. Quelle que soit la forme arrivée, l'ID extrait est le même — la sortie décodée est donc identique à l'octet près sur les sept lignes du tableau.

Formats refusés

Deux refus méritent une explication. La route de l'app web x.com/i/web/status/… apparaît quand le client monopage réécrit les adresses en interne, mais elle omet le segment du nom d'utilisateur, donc elle n'entre pas dans la grammaire ci-dessus — collez la forme canonique et le même ID se décode normalement. Et regardez bien la dernière ligne — un ID Discord passe le contrôle de longueur et se décode vers une date d'allure plausible. Le décodeur ne peut pas le détecter, et cette limite est documentée honnêtement plutôt que maquillée.

Anatomie d'un Snowflake ID

Un snowflake est un entier 64 bits découpé en quatre champs. Lu depuis le bit de poids fort :

L'époque

Les horodatages ne comptent pas depuis 1970 — ils comptent depuis le 4 novembre 2010 à 01:42:54,657 UTC, le moment où le service snowflake a remplacé les IDs séquentiels. Choisir une époque fraîche garde le champ d'horodatage petit — 41 bits contiennent environ 2 200 milliards de millisecondes, soit environ 69,7 ans de marge. Le format ne court donc à sec qu'en juillet 2080 — confortablement loin, et l'une des raisons pour lesquelles le champ ne peut être élargi sans casser tous les clients existants.

Un exemple travaillé

Prenons l'ID utilisé partout dans les outils X de ce site — 2089759704335482961. Tranché aux frontières des champs, on y lit d'un coup d'œil chaque valeur que le décodeur imprime :

Le zéro de tête de la ligne d'horodatage est le bit de signe, toujours nul. Chaque ligne de sortie découle de cette seule découpe — les bits d'horodatage deviennent l'instant de publication, le champ worker désigne la machine 376, et la séquence montre que c'était l'ID numéro 81 frappé par cette machine dans cette milliseconde.

Combien d'IDs tiennent

La séquence sur 12 bits permet jusqu'à 4 096 IDs par machine et par milliseconde, et le champ worker sur 10 bits nomme jusqu'à 1 024 machines. En pratique, la séquence grimpe rarement près de son plafond — elle existe pour que jamais ne se percutent les rafales, non pour le total. Deux IDs de la même machine dans la même milliseconde ne diffèrent que par ces douze bits bas.

La chronologie des chiffres

Comme l'horodatage occupe les bits hauts, la valeur totale grandit sans relâche — le nombre de chiffres décimaux dit à peu près quand un ID a été frappé :

C'est pourquoi le décodeur accepte 15 à 19 chiffres et rien d'autre — 15 couvre les toutes premières publications de l'ère snowflake, 19 tout ce qui a été frappé depuis 2018, et aucun ID de tweet légitime n'a jamais franchi cette fourchette.

Comment fonctionne le décodage

Les maths tiennent en trois opérations — un décalage, deux masques et une addition :

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

timestampMs = Number((id >> 22n) + TWEET_EPOCH);
workerId    = Number((id >> 12n) & 1023n);    // les 10 bits bas du champ central
sequence    = Number(id & 4095n);             // les 12 bits bas

Décaler de 22 bits vers la droite jette les champs worker et séquence et laisse le décalage d'horodatage depuis l'époque propre ; ajouter l'époque le convertit en millisecondes Unix ordinaires. Les masques isolent ensuite les deux champs bas — & 1023 garde dix bits, & 4095 douze. En retravaillant l'exemple, 2089759704335482961 décalé donne un décalage de 498237539371 millisecondes, qui additionné à l'époque vaut 1787072514028, c'est-à-dire 2026-08-18T17:01:54.028Z ; le worker masqué est 376 et la séquence 81.

Deux détails de précision comptent. D'abord, l'outil fait toute l'arithmétique en BigInt, car un ID à 19 chiffres dépasse la plage entière sûre de JavaScript (9 007 199 254 740 991) et un nombre ordinaire arrondirait silencieusement les bits bas — corrompant justement les valeurs worker et séquence que l'outil rapporte. Ensuite, une fois converti, l'horodatage résultant tient aisément dans la plage sûre, si bien que le présenter comme nombre ordinaire à Date ne perd rien.

Autre chose qui vaut la peine d'être su — d'autres plateformes tranchent ces mêmes 22 bits bas autrement, et les décodeurs génériques les étiquettent souvent avec les noms de champs d'un système étranger :

Si un outil vous montre votre ID de tweet partagé entre workerOrShard et processId, il applique les étiquettes de Discord aux bits de X — les nombres se calculent, mais un tweet n'a pas de champ processus, et les douze bits bas sont un compteur de séquence, pas un identifiant de processus. Ce décodeur s'en tient aux champs que X définit réellement.

Utilisation

Quatre étapes, aucun bouton :

1. Collez votre entrée — un ID de tweet nu, ou tout lien de statut x.com/twitter.com sous les formes listées plus haut.
2. Lisez le groupe temporel — heure locale, UTC, ISO 8601 et millisecondes Unix se remplissent instantanément, et la ligne relative donne l'âge d'un coup d'œil.
3. Lisez le groupe anatomique — worker ID, séquence et le binaire groupé montrent comment le nombre est bâti.
4. Copiez ce dont vous avez besoin — chaque ligne a son bouton de copie ; la ligne ISO glisse proprement dans les tableurs et les logs.

Une entrée invalide vide les lignes et affiche une seule ligne d'erreur ; corriger l'entrée efface l'erreur aussi automatiquement.

Tutoriel pas à pas

Parcourez un décodage de bout en bout.

Étape 1 — Décoder un ID nu. Collez 2089759704335482961 dans l'entrée. Le groupe temporel se remplit aussitôt — ligne ISO 2026-08-18T17:01:54.028Z, ligne Unix 1787072514028 — et le groupe anatomique rapporte worker 376, séquence 81, avec le binaire dans ses groupes 42/10/12.

Étape 2 — Décoder depuis un lien complet. Videz l'entrée et collez https://x.com/jack/status/2089759704335482961?s=20&t=abc. Les paramètres de suivi ne changent rien — chaque ligne se lit identique à l'étape 1, car seule la route de statut et l'ID survivent à l'extraction.

Étape 3 — Confirmer l'indépendance de domaine. Collez https://www.twitter.com/someone/status/2089759704335482961/ — l'ancien domaine avec préfixe d'utilisateur et barre oblique finale. Même ID, même horodatage. Peu importe comment le lien vous est parvenu — le nombre qu'il porte est l'unique source de vérité.

Étape 4 — Voir échouer un ID impossible. Collez 20 — l'ID du premier tweet jamais publié, de l'ère précédant le snowflake. Le décodeur le refuse — deux chiffres ne peuvent porter un horodatage encodé, car cet ID a été émis des années avant que le format existe. Le refus est correct, pas un bug.

Étape 5 — Emmener la sortie là où elle sert. Cliquez sur le bouton de copie de la ligne ISO et collez dans une cellule de tableur — 2026-08-18T17:01:54.028Z se trie chronologiquement en texte, survit aux allers-retours CSV et n'a besoin d'aucun contexte de fuseau horaire pour être lu.

Conseils de pro

• Trier par ID, c'est trier par temps. Partout où des IDs de tweets vivent dans une colonne — exports, bases de données, logs — l'ordre par ID est l'ordre chronologique. Le décodeur aide à étiqueter cet ordre avec de vraies dates.
• Préférez la ligne ISO pour le stockage. L'heure locale dépend des réglages de l'appareil de celui qui lit ; ISO 8601 avec le suffixe Z est sans ambiguïté partout et se trie correctement en texte brut.
• UTC pour les équipes entre fuseaux. Quand une archive couvre des continents, mettez-vous d'accord sur la ligne UTC et personne ne discutera de savoir si la publication a passé minuit.
• Servez-vous de la ligne relative pour le triage. En passant en revue un lot d'IDs, l'âge compact — 3h, 2d, 5mo — sépare le frais de l'ancien plus vite que la lecture de dates complètes.
• La ligne binaire est un outil pédagogique. Montrer à quelqu'un quels bits sont exactement l'horodatage fait cliquer tout le format plus vite que n'importe quel diagramme.
• Jumelez-le avec l'analyseur d'URLs. L'analyseur nettoie et canonise les liens ; le décodeur les date. Passez le même lien de statut par les deux et vous repartez avec une URL nette et un horodatage vérifié.

Alternatives

Comment d'autres façons un ID de tweet peut-il devenir une date ?

Décoder à la main, c'est des puissances de deux et de longues chaînes binaires — faisable une fois, pénible pour toujours, et un bit dérapé ruine la date. Les décodeurs en ligne génériques visent souvent Discord d'abord, étiquettent mal les champs X et se trompent parfois d'époque, et ils envoient couramment l'ID à un serveur. Cet outil exécute l'arithmétique exacte en local, étiquette les champs comme X les définit et refuse les entrées impossibles au lieu d'afficher une année fausse en toute assurance.

Face aux API officielles

Lire une heure de création est la tâche rare où la voie officielle est strictement pire :

Depuis février 2026, l'API de X est payante à l'usage sans offre gratuite — obtenir created_at fût-ce pour un seul tweet coûte de l'argent et exige des identifiants enregistrés. oEmbed renvoie du HTML rendu pour l'intégration, sans champ d'horodatage structuré exploitable de façon fiable. L'arithmétique snowflake livre la même milliseconde gratuitement, hors ligne et pour toujours — le prix, c'est qu'elle ne révèle rien au-delà du nombre lui-même, précisément la limite documentée ci-dessous.

Décodeur vs. analyseur d'URLs

Toollect expédie deux outils X qui lisent tous deux des liens de statut et connaissent tous deux les IDs snowflake. Ils répondent à des questions différentes :

L'analyseur est le généraliste des liens ; le décodeur, le spécialiste des nombres. Son acceptation des URLs complètes est un confort — dès qu'un lien demande nettoyage, saisie ou explication, c'est territoire de l'analyseur, et les deux outils se passent le témoin proprement à l'ID.

Ce que l'outil ne fait pas

Les limites méritent d'être nommées pour que le décodeur ne soit jamais trop cru :

• Il ne va chercher rien. Zéro requête — l'outil ne peut pas voir si le tweet existe encore, qui l'a écrit ni ce qu'il dit. De l'ID ne sort que ce qui y a été enfourné à la naissance.
• Il ne peut pas inverser la conversion. Renvoyer une date vers un ID fabrique un nombre qu'aucun tweet n'a jamais reçu — ouvrez x.com/i/status/{fabriqué} et X répond que la page n'existe pas. Les IDs synthétiques n'ont servi que de seuils de pagination dans l'ancienne API gratuite ; sur le web d'aujourd'hui, les opérateurs de recherche par date font ce travail directement.
• Il ne distingue pas les plateformes. Un snowflake Discord partage la structure et se décode ici sans erreur — à une date en avance d'environ quatre ans, car Discord compte depuis 2015. Si l'entrée vient d'une autre plateforme, considérez la sortie comme fausse par construction.
• Il ne décode pas les IDs d'avant 2010. Les tweets plus vieux que le service snowflake portent de petits numéros séquentiels sans horloge embarquée — il n'y a littéralement rien à décoder.
• Il ne devine pas. Une entrée qui ne correspond à aucune forme acceptée affiche le message d'erreur plutôt qu'un résultat partiel.

Dépannage

Confidentialité et traitement des données

Ce décodeur opère sous le modèle de confidentialité le plus strict du site — il ne fait aucune requête réseau.

• Rien n'est téléversé. Décoder, c'est de l'arithmétique de bits dans votre navigateur. L'ID ou le lien que vous collez n'atteint jamais aucun serveur.
• Pas de compte, pas d'analytique, pas de scripts tiers. La page n'exécute que son propre code.
• Rien n'est conservé. Pas de cookies, pas d'état entre les visites — fermez l'onglet et la session disparaît.

Pour les flux de travail impliquant des IDs d'archives privées, de jeux de données de recherche ou de files de modération, le décodage se produit entièrement sur votre appareil.

Spécifications techniques

Détails :

• Format — snowflake 64 bits — signe (1 bit) + horodatage (41 bits, ms depuis le 2010-11-04T01:42:54.657Z) + worker (10 bits) + séquence (12 bits)
• Précision — arithmétique BigInt de bout en bout ; résultats exacts pour tous les IDs à 19 chiffres hors de la plage entière sûre de JavaScript
• Fenêtre de validation — l'heure décodée ne peut dépasser l'heure actuelle de plus de 60 secondes ; les valeurs antérieures à l'époque sont inaccessibles dès 15 chiffres
• Formats d'entrée — \d{15,19} nu, ou URLs de statut x.com/twitter.com avec protocole optionnel, sous-domaines www./mobile./m., variantes de vue et chaînes de requête
• Sortie — heure locale, chaîne UTC, ISO 8601, millisecondes Unix, âge relatif, worker ID, séquence, binaire 64 bits groupé — chaque ligne copiable individuellement
• Traitement — JavaScript 100 % côté client, zéro requête réseau, pas de clé API, aucun composant serveur
• Support navigateurs — tous les navigateurs modernes (BigInt et Clipboard API)

Fonctionnalités

• Décode tout ID snowflake X ou Twitter en son moment exact de publication, à la milliseconde
• Accepte les IDs de tweet nus et les liens de statut x.com ou twitter.com complets — l'ID est extrait automatiquement
• Présente l'instant décodé de quatre façons — heure locale, UTC, ISO 8601 et millisecondes Unix
• Décompose l'ID en ses parties — worker ID, compteur de séquence et binaire complet sur 64 bits
• Rejette les valeurs impossibles — un ID daté du futur affiche une erreur au lieu d'une supposition
• Fonctionne entièrement dans votre navigateur sans requête réseau — sans clé API ni compte
• Copie en un clic sur chaque ligne de résultat

Questions fréquentes