Générateur NanoID

Générez des NanoID en ligne: 21 caractères URL-safe par défaut, environ 126 bits d’aléa, avec longueur et alphabet modifiables.

Format
ID générés
Prêt. Générez des NanoID dans votre navigateur.

Comment cet ID est construit

Structure
21 caractères URL-safe par défaut parmi A-Z, a-z, 0-9, tiret bas et tiret.
Entropie
Environ 126 bits avec l’alphabet par défaut de 64 caractères et la longueur 21.
Temps
Aucun horodatage; NanoID reste opaque sauf si vous ajoutez du sens dans un alphabet personnalisé.
Risque de collision
Le risque varie avec la longueur et l’alphabet. Le réglage par défaut est dans une zone pratique proche de UUID v4.
Exemple
HkJEOm1AU1A_F5ZRsBLXG

Vos ID sont générés localement avec l’aléa fort du navigateur. Rien n'est envoyé à BroBroGo.

FAQ

Pourquoi utiliser NanoID ?

NanoID est plus court qu’un UUID, URL-safe par défaut et garde un fort aléa si vous conservez la longueur et l’alphabet par défaut.

Puis-je changer l’alphabet ?

Oui. La page NanoID verrouillée conserve les contrôles de longueur et d’alphabet. Un alphabet plus petit ou une longueur plus courte augmente le risque de collision.

Qu'est-ce que Nano ID et pourquoi l'utiliser?

Nano ID est un format d'identifiant unique conçu pour être à la fois compact, sûr pour les URL et résistant aux collisions. Contrairement à un UUID classique (36 caractères) ou à un ULID (26 caractères), Nano ID utilise par défaut 21 caractères – soit une réduction de près de 42 % par rapport à un UUID tout en offrant une probabilité de collision comparable. Ce gain de taille se traduit par un moindre encombrement en stockage et une transmission plus rapide, notamment dans les API, les clés de base de données ou les codes QR.

La page Nano ID Generator permet de produire ces identifiants directement dans le navigateur, sans aucun échange avec un serveur. Vous contrôlez trois paramètres: la longueur de l'identifiant, l'alphabet autorisé et le nombre d'identifiants à générer (de 1 à 100). Chaque modification entraîne une régénération immédiate, ce qui facilite l'exploration et le régl fin.

Paramètres ajustables: longueur, alphabet et nombre d'identifiants

L'outil expose une interface minimale mais complète. La longueur est réglable par curseur entre 2 et 36 caractères; la valeur par défaut est 21, celle recommandée par la spécification Nano ID. Pourquoi 21 plutôt que 36? Parce qu'avec un alphabet de 64 symboles (URL-safe), une taille de 21 donne environ 2^126 combinaisons possibles – largement suffisant pour éviter les collisions dans la quasi-totalité des applications pratiques. Les puristes peuvent descendre à 2 (réservé à des cas très particuliers) ou monter à 36 (équivalent à la longueur d'un UUID mais avec un alphabet plus riche).

L'alphabet est un champ texte éditable. Il contient par défaut l'ensemble des caractères URL-safe: lettres minuscules (26), majuscules (26), chiffres (10) plus les symboles -_ (tiret et underscore), soit 64 caractères. Vous pouvez le réduire à un sous-ensemble: par exemple uniquement des chiffres (pour un code PIN court), ou seulement des lettres minuscules sans ambiguïté (abcdefghjkmnpqrstuvwxyz). L'outil vérifie que l'alphabet comporte au moins deux caractères différents; si ce n'est pas le cas, les identifiants sont effacés, le compteur passe à 0 et le bouton "Copier tout" est désactivé.

Le nombre d'identifiants est compris entre 1 et 100. Une fois générés, chaque identifiant est affiché dans une liste cliquable: un simple clic copie l'identifiant dans le presse-papiers. Un bouton "Copier tout" permet de récupérer l'ensemble des identifiants d'un coup, séparés par un saut de ligne.

Comment la génération locale garantit sécurité et rapidité

La génération ne repose sur aucun serveur distant. Le code JavaScript de la page utilise crypto.getRandomValues() – une primitive cryptographique disponible dans tous les navigateurs modernes – pour produire des nombres aléatoires de qualité équivalente à celle d'un générateur de nombres aléatoires sécurisé (CSPRNG). Cela signifie que les identifiants ne peuvent pas être prédits, même si un attaquant connaît l'algorithme.

Aucune donnée ne quitte votre machine. Aucun identifiant n'est envoyé à BroBroGo ni à quelque service tiers. Cette architecture est particulièrement importante pour les développeurs soucieux de la vie privée ou travaillant dans des environnements réglementés (RGPD, HIPAA). Le temps de génération est négligeable: quelques microsecondes pour 100 identifiants de 21 caractères.

L'outil ne conserve aucun historique en session. Une régénération avec les mêmes paramètres produira des identifiants différents, car le tirage est aléatoire à chaque fois.

Cas particuliers et comportement de l'outil

Plusieurs garde-fous évitent les erreurs courantes.

  • Alphabet trop court: si vous supprimez des caractères jusqu'à n'en laisser qu'un seul, les identifiants déjà affichés disparaissent, le compteur passe à 0, et le bouton "Copier tout" est désactivé. Un message d'erreur explicite s'affiche: Alphabet needs at least 2 different characters. Cette règle est logique: avec un unique caractère, un identifiant de longueur L ne peut prendre qu'une seule valeur (par exemple "aaaa…"); il n'y a donc aucun intérêt à générer plusieurs identifiants différents.

  • Modification immédiate: tout changement de longueur, d'alphabet ou de nombre d'identifiants déclenche une régénération automatique. Vous n'avez pas à cliquer sur un bouton "Générer". Cela peut surprendre au début, mais garantit que l'affichage reflète toujours les paramètres courants.

  • Copie individuelle: un clic sur un identifiant le copie dans le presse-papiers et change le statut en "Copied!". Le statut général de l'outil indique "Ready." lorsqu'il est inactif, "Generated." après une génération, et "Copied all!" lorsque tous les identifiants ont été copiés via le bouton principal.

  • Gamme de longueur: la longueur minimale de 2 caractères empêche la création d'identifiants d'un seul caractère, qui ne seraient pas résistants aux collisions. La valeur maximale de 36 permet de s'aligner sur la taille d'un UUID si l'on souhaite une compatibilité visuelle.

Collisions et choix de la longueur optimale

La probabilité de collision dépend à la fois de la longueur et de la taille de l'alphabet. Plus l'alphabet est grand, plus le nombre de combinaisons possibles augmente. La formule simple est: nombre de combinaisons = (taille de l'alphabet) ^ longueur. Pour un alphabet par défaut de 64 caractères et une longueur de 21, cela donne 64^21 ≈ 2^126 combinaisons – une valeur astronomique. En comparaison, un UUID version 4 offre 2^122 combinaisons: Nano ID propose donc une marge légèrement supérieure avec une longueur moindre.

En pratique, si vous réduisez l'alphabet à 10 chiffres (comme pour un code de vérification à 6 chiffres), le nombre de combinaisons chute à 10^6 = 1 million. Avec 100 000 utilisateurs, la probabilité de collision devient significative. L'outil vous permet de tester rapidement différents couples (longueur, alphabet) et d'observer le résultat visuellement.

Pour une clé primaire de base de données, une longueur de 21 avec l'alphabet complet est le choix par défaut recommandé. Pour un lien de partage temporaire, on peut descendre à 8 ou 10 caractères. Pour un identifiant visible publiquement (comme un identifiant de canal), 12 à 16 caractères suffisent généralement. L'outil ne calcule pas lui-même la probabilité de collision, mais la documentation de Nano ID propose des tables: avec 64 symboles, 21 caractères garantissent moins d'une collision sur 1 000 000 000 000 000 000 000 000 000 000 000 000 de tirages.

Utilisations concrètes pour les développeurs et architectes

Les cas d'usage sont nombreux.

  • API REST: remplacer les UUID par des Nano ID plus courts dans les endpoints, réduisant la taille des JSON et des URLs.
  • Clés primaires: dans une base NoSQL (MongoDB, Firestore) ou relationnelle, un identifiant court améliore les performances d'indexation.
  • Codes QR: le contenu d'un QR code étant limité en densité, un identifiant de 21 caractères tient mieux qu'un UUID de 36.
  • Tokens éphémères: pour des liens de réinitialisation de mot de passe ou d'invitation, une longueur de 12 à 16 caractères avec alphabet complet offre un bon équilibre.
  • Identifiants publics: sur une plateforme sociale, les identifiants de profils ou de posts peuvent être visibles; il est important d'utiliser un alphabet non ambigu (sans O/0, l/1). L'alphabet par défaut inclut ces caractères, mais vous pouvez les retirer manuellement.

Les architectes systèmes apprécient aussi la possibilité de paramétrer l'alphabet pour respecter des contraintes réglementaires (pas de caractères spéciaux dans certains contextes) ou pour éviter les confusions de lecture.

Questions fréquentes (FAQ)

Puis-je générer plus de 100 identifiants? Non, la limite est fixée à 100 par l'interface. Si vous en avez besoin de davantage, vous pouvez générer plusieurs lots et les concaténer manuellement.

Est-il possible d'utiliser des caractères accentués dans l'alphabet? Techniquement oui, mais ce n'est pas recommandé: les identifiants ne seraient plus URL-safe et pourraient poser des problèmes d'encodage. L'alphabet par défaut respecte la spécification URL-safe (A-Z, a-z, 0-9, tiret, underscore).

Pourquoi l'alphabet doit-il contenir au moins 2 caractères différents? Avec un seul caractère, tous les identifiants seraient identiques; générer plusieurs IDs n'aurait aucun sens. La règle évite de produire des listes inutiles et garantit une diversité minimale.

Quel est l'avantage de la génération locale par rapport à une API? Aucune donnée n'est transmise sur le réseau, ce qui élimine les risques de fuite d'identifiants sensibles et les latences réseau. La génération est instantanée et fonctionne hors ligne.

Puis-je utiliser les identifiants générés en production? Oui, car l'algorithme utilise un générateur aléatoire sécurisé (crypto.getRandomValues). La qualité aléatoire est celle des API cryptographiques du navigateur.

Que se passe-t-il si je règle la longueur à 2 et l'alphabet à 64 caractères? Vous obtiendrez des identifiants de 2 caractères (ex: "a3", "X_"). Le nombre de combinaisons est alors de 64^2 = 4 096. Cela peut suffire pour un petit ensemble de variables, mais les collisions deviennent probables au-delà de 100 éléments. L'outil ne vous en empêche pas, mais à vous de juger vos besoins.