Générateur de clé aléatoire
Hexadécimal, Base64 ou UUID v4 — une valeur aléatoire prête à l'emploi, générée dans votre navigateur.
Comment cette clé est générée
Le générateur demande au navigateur un bloc d'octets aléatoires via crypto.getRandomValues(), l'interface de l'API Web Crypto adossée au générateur d'aléa du système d'exploitation. Ces octets bruts sont ensuite simplement représentés sous la forme choisie : en hexadécimal, chaque octet devient deux caractères de 0 à f ; en Base64, les octets sont regroupés par trois et rendus par quatre caractères imprimables. Le format d'affichage ne change donc rien à la solidité de la clé : 32 octets tirés au hasard, ce sont 256 bits d'aléa, qu'on les écrive sur 64 caractères hexadécimaux ou 44 caractères Base64.
L'option UUID v4 suit un chemin voisin : elle appelle crypto.randomUUID(), qui produit un identifiant de 128 bits dont 6 sont fixés par la norme pour indiquer la version et la variante — il reste donc 122 bits réellement aléatoires. C'est assez pour que deux machines puissent générer des identifiants chacune de leur côté sans jamais se coordonner, avec un risque de collision négligeable en pratique.
Toute l'opération se déroule dans votre navigateur. La valeur affichée n'est envoyée à aucun serveur, n'est écrite dans aucun stockage local et n'est pas conservée d'une génération à l'autre : dès que vous régénérez ou fermez la page, la précédente n'existe plus nulle part.
Cas d'usage courants
- Secret de signature de session ou de jeton — la valeur placée derrière un
SESSION_SECRETou unJWT_SECRETdans un fichier d'environnement. 32 octets est la taille de référence. - Clé d'API interne — pour authentifier un service auprès d'un autre lorsque vous contrôlez les deux côtés.
- Sel ou vecteur d'initialisation — une valeur unique, non secrète, mais qui doit être imprévisible et ne jamais être réutilisée.
- Identifiant unique (UUID v4) — clé primaire d'un enregistrement, identifiant de corrélation dans des journaux, nom de fichier garanti sans collision.
- Jeu de données de test — remplir un environnement de recette avec des identifiants réalistes sans réutiliser ceux de production.
Quel que soit l'usage, une clé se traite comme un secret : elle se stocke dans une variable d'environnement ou un gestionnaire de secrets, jamais en clair dans un dépôt de code, et se remplace dès qu'un doute existe sur son exposition. Un UUID v4, en revanche, n'est pas un secret : il est conçu pour être unique, pas pour être confidentiel, et ne doit donc pas servir de jeton d'accès.
Longueurs et formats de sortie
Le curseur va de 8 à 64 octets. Le nombre de caractères affichés dépend ensuite du format choisi, sans jamais changer la quantité d'aléa.
| Taille | Aléa | Hexadécimal | Base64 | Usage typique |
|---|---|---|---|---|
| 16 octets | 128 bits | 32 caractères | 24 caractères | Sel, identifiant non devinable, jeton court |
| 24 octets | 192 bits | 48 caractères | 32 caractères | Clé imposée par un format en 192 bits |
| 32 octets | 256 bits | 64 caractères | 44 caractères | Défaut recommandé : secret de session, clé d'API |
| 64 octets | 512 bits | 128 caractères | 88 caractères | Clé HMAC-SHA512 à la taille de la sortie du hash |
| UUID v4 | 122 bits | 36 caractères | — | Identifiant unique, jamais un secret |
Au-delà de 32 octets, une clé symétrique n'apporte plus rien face à une attaque par force brute : 256 bits sont déjà hors d'atteinte. Une taille supérieure ne se justifie que si un format ou une spécification l'impose.
Non. La génération se fait entièrement dans votre navigateur avec l'API Web Crypto (crypto.getRandomValues, crypto.randomUUID), une source d'aléa cryptographiquement sûre.
Un UUID v4 est généré de façon quasiment entièrement aléatoire (122 bits d'aléa), ce qui le rend adapté comme identifiant unique sans coordination centrale. D'autres versions (v1, v7) intègrent un horodatage ou une adresse réseau — un usage différent, hors du périmètre de ce générateur.
32 octets (256 bits) est un bon défaut pour une clé d'API ou un secret de session — largement au-delà de ce qu'une attaque par force brute peut espérer casser dans un temps raisonnable.
Les deux représentent exactement les mêmes octets, avec la même quantité d'aléa : seule la longueur du texte diffère. L'hexadécimal produit 2 caractères par octet et n'utilise que 0-9 et a-f, ce qui le rend sûr dans une URL ou un nom de variable. Le Base64 est plus compact (environ 1,33 caractère par octet) mais contient des caractères +, / et = qu'il faut parfois échapper. Choisissez selon le format attendu par l'outil de destination.
Rien n'est conservé : la valeur n'existe que dans la page ouverte et disparaît au rechargement. Elle est tirée par crypto.getRandomValues(), le générateur cryptographique du système, et non par Math.random(). Deux générations successives sont indépendantes, et personne d'autre — y compris ce site — ne voit la valeur produite.
Non, et ce n'est pas son usage. Une clé hexadécimale ou Base64 est faite pour être copiée dans un fichier de configuration ou un gestionnaire de secrets, pas retenue ni saisie au clavier. Pour un mot de passe destiné à un compte, utilisez le générateur de mot de passe ; pour un secret à mémoriser, le générateur de phrase de passe.