Générez des tokens aléatoires cryptographiquement sûrs en hexadécimal, Base64URL ou alphanumérique — dans votre navigateur.
Clés d'API, identifiants de session, secrets de webhooks, codes de réinitialisation de mot de passe et jetons CSRF partagent une même exigence : être impossibles à deviner. Cela exclut Math.random(), les horodatages et tout ce qui en dérive — assez prévisibles pour être forcés par force brute. Ce générateur utilise crypto.getRandomValues, le générateur pseudo-aléatoire cryptographiquement sûr (CSPRNG) que les navigateurs alimentent avec l'entropie du système d'exploitation — la même source qui sert à créer les clés TLS.
L'option de longueur définit le nombre d'octets aléatoires de chaque token (16 à 128, 32 par défaut) — ou, en mode alphanumérique, le nombre de caractères. L'hexadécimal encode chaque octet en deux caractères de 0-9a-f ; Base64URL condense les mêmes octets en une chaîne plus courte et sûre dans les URL, faite de lettres, de chiffres, du tiret et du tiret bas ; l'alphanumérique tire ses caractères du jeu de 62 caractères A-Z a-z 0-9. Le mode alphanumérique mérite une note technique : 256 n'étant pas divisible par 62, prendre naïvement chaque octet aléatoire modulo 62 ferait apparaître certains caractères plus souvent que d'autres (biais de modulo). Ce générateur applique plutôt l'échantillonnage par rejet — les octets supérieurs ou égaux à 248 sont écartés et retirés à nouveau — de sorte que chaque caractère est exactement équiprobable.
La ligne d'état affiche l'entropie estimée : 8 bits par octet pour l'hexadécimal et Base64URL, log2(62) ≈ 5,95 bits par caractère pour l'alphanumérique. En règle générale, 128 bits sont déjà hors de portée de la force brute et 256 bits — la valeur par défaut de 32 octets — sont le standard pour les clés d'API de longue durée. Tout est généré localement dans votre navigateur : aucun serveur ne voit jamais les tokens, ils peuvent donc servir de vrais secrets. Traitez-les en conséquence : ne stockez côté serveur qu'un hash du token, affichez la valeur en clair une seule fois, et faites tourner les clés que vous soupçonnez d'avoir été exposées.
Entropie = longueur × log2(taille de l'alphabet). Un token de 32 octets porte 256 bits d'entropie quel que soit l'encodage ; un token alphanumérique porte log2(62) ≈ 5,95 bits par caractère, donc 43 caractères alphanumériques ≈ 256 bits.
32 octets (256 bits) sont un solide choix par défaut pour les clés d'API de longue durée, et 16 octets (128 bits) le minimum pratique pour tout ce qui touche à la sécurité. Des tokens plus longs ne coûtent rien ici, alors voyez large.
C'est la distribution inégale obtenue en projetant 256 valeurs d'octet sur un alphabet qui ne divise pas 256 exactement — certains caractères deviennent légèrement plus probables, ce qui réduit de façon mesurable l'entropie effective. Cet outil l'évite par échantillonnage par rejet, en écartant les octets au-delà du plus grand multiple exact de la taille de l'alphabet.
Non. Les tokens sont produits localement par crypto.getRandomValues et ne sont jamais transmis, journalisés ni stockés — cette page n'effectue aucune requête réseau, les tokens peuvent donc servir de vrais secrets.
Seul l'encodage change — la source d'aléa est la même. L'hexadécimal est le plus long mais lisible partout ; Base64URL est environ un tiers plus court et sûr dans les URL ; l'alphanumérique évite toute ponctuation, ce qui aide quand un système restreint les caractères autorisés.
En théorie oui, en pratique non : à 256 bits, la probabilité de voir un jour un doublon est très inférieure à celle d'une panne matérielle. Cette résistance aux collisions est précisément ce qui fait des tokens aléatoires imprévisibles de bons identifiants de secrets.
Vai.la transforme n'importe quelle URL en lien court avec statistiques de clics, QR Code et votre propre biolink.
Vai.la n'est pas responsable de l'utilisation des outils ni des décisions prises sur la base de leurs résultats.