Saisissez n'importe quel texte ci-dessous pour voir instantanément ses hashs SHA-1, SHA-256, SHA-384 et SHA-512. Tous les quatre sont calculés dans votre navigateur via l'API Web Crypto native. Votre saisie ne quitte jamais votre machine.
Une fonction de hash cryptographique prend n'importe quelle entrée et produit une sortie de longueur fixe (32, 64 ou 128 caractères hex selon l'algorithme). Deux propriétés clés la rendent utile : des entrées identiques produisent toujours des sorties identiques, et un changement minuscule dans l'entrée modifie complètement la sortie. Inverser un hash vers son entrée est calculatoirement infaisable.
Les hashs sont partout : vérifier qu'un fichier téléchargé correspond au checksum de l'éditeur, indexer le contenu dans des systèmes de versioning comme Git, dériver des clés de cache, signer des tokens JWT, et stocker des mots de passe (avec un sel supplémentaire et des fonctions volontairement lentes comme bcrypt ou argon2).
Non. Les hashs sont calculés localement avec l'API Web Crypto du navigateur. Rien ne quitte votre machine — sûr même avec des données sensibles.
L'API Web Crypto n'implémente pas MD5 car il est cassé et ne devrait pas être utilisé en contexte de sécurité. Si vous avez besoin de MD5 uniquement pour un usage non-sécuritaire (ex : compatibilité avec un système legacy), utilisez un outil dédié — l'ajouter via WebAssembly est dans la feuille de route.
Pour l'instant, l'outil n'accepte que du texte en entrée. Le hash de fichier par glisser-déposer est dans la feuille de route. En attendant, collez le contenu du fichier (par ex. un petit JSON ou fichier de config) dans la zone d'entrée.
Oui. La famille SHA-2 (SHA-256, SHA-384, SHA-512) n'a aucune collision pratique connue et reste la recommandation par défaut pour le hashage cryptographique général. SHA-3 est aussi disponible dans l'API Web Crypto de certains navigateurs mais n'est pas encore largement répandu. Évitez MD5 et SHA-1 pour tout usage sécuritaire — les deux sont considérés cassés.
Le hashage est à sens unique : à partir de la sortie, vous ne pouvez pas retrouver l'entrée. Le chiffrement est à double sens : avec la bonne clé, vous pouvez déchiffrer pour retrouver les données originales. Utilisez le hashage pour les empreintes (intégrité de fichier, stockage de mots de passe avec bcrypt/argon2, déduplication, cache content-addressed). Utilisez le chiffrement (AES, ChaCha20) quand vous avez besoin de relire les données plus tard.
Situations réelles où un hash rapide est exactement ce qu'il faut.
Collez ici le contenu téléchargé et comparez son SHA-256 à la somme de contrôle de l'éditeur. Une différence signifie que le fichier a été altéré ou corrompu.
Hashez le payload de la requête pour dériver une clé de cache stable. Des entrées identiques produisent la même clé, donc les hits de cache fonctionnent entre machines et déploiements.
Empreignez chaque entrée par SHA-256 et comparez les hashes. Deux valeurs identiques mappent toujours sur le même hash, donc trouver les doublons est en O(n).
Testez la vérification de signature côté récepteur en hashant ici le corps + le secret, puis comparez à l'en-tête X-Signature émis par votre service.
Habitudes qui rendent le hashage plus sûr et plus rapide.
Il couvre 99 % des cas d'usage — sommes de contrôle, cache content-addressed, signatures. Réservez SHA-512 aux protocoles existants qui l'imposent.
Les deux sont cassés en sécurité. Ils restent acceptables pour des contrôles d'intégrité non-adversariaux (clés de cache, dédup) mais pas pour ce qu'un attaquant pourrait exploiter.
Pour stocker mots de passe ou clés API, hashez avec une fonction lente comme argon2 ou bcrypt. Un hash que l'on ne peut inverser est bien plus sûr qu'un chiffrement dont on pourrait fuir la clé.
Changez un seul bit en entrée, la sortie change complètement. Cette propriété rend les hash excellents pour repérer toute altération, même minime.