Générateur de Hash

Génère MD5, SHA-1, SHA-256, SHA-384, SHA-512 et HMAC, puis compare un checksum, le tout dans ton navigateur.

Ce générateur de hash calcule MD5, SHA-1, SHA-256, SHA-384, SHA-512 et HMAC pour n'importe quel texte ou petit fichier, directement dans ton navigateur, donc les octets ne quittent jamais la page. Colle une chaîne ou dépose un fichier, colle un digest attendu pour comparer, bascule la sortie entre hex et Base64, et signe un message avec un secret HMAC quand tu dois prouver qu'il vient d'un détenteur de la clé partagée. MD5 et SHA-1 restent disponibles, clairement marqués legacy, pour les vieux checksums que tu dois encore vérifier, tandis que SHA-256 reste le choix par défaut raisonnable pour tout ce qui est moderne. Les notes signalent quelles sorties sont sûres et lesquelles ne devraient jamais s'approcher d'une vraie décision de sécurité, car un hash est une empreinte, pas du chiffrement, et les mots de passe appartiennent à un KDF lent comme Argon2, bcrypt ou scrypt.

100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.

Atelier local de hash, checksum, MD5 legacy et HMAC

Honnêtement, je l'ai bricolé par dépit. Chaque fois que le checksum d'un téléchargement ne collait pas, je partais à la chasse d'une page de hash en qui j'avais vraiment confiance, et la moitié d'entre elles expédient ton texte vers je ne sais quel serveur. Donc voilà. Tu colles du texte ou tu déposes un petit fichier. Tu obtiens MD5, SHA-1, SHA-256, SHA-384 et SHA-512, calculés directement dans ton navigateur. Colle un digest attendu pour comparer. Bascule entre hex et Base64. Signe quelque chose avec HMAC. Et le truc que tout le monde rate, savoir quand un hash est le bon choix par rapport à quand tu voulais en fait une signature ou un vrai hachage de mot de passe, c'est expliqué plus bas.

Texte à hasher

Checksum attendu à comparer

Format de sortie

Algorithme HMAC

Secret HMAC

Fichier local optionnel

Octets d'aperçu

Tout tourne en local, donc ton texte, ton fichier, ton secret, rien de tout ça ne quitte la page. Et je le répéterai autant de fois qu'il faudra : ne stocke pas tes mots de passe en MD5 brut ou en simple digest SHA. Mauvais outil pour ce boulot.

Un générateur de hash sert à faire des empreintes, pas du secret

Un générateur de hash produit une empreinte : mêmes octets en entrée, même digest en sortie, à chaque fois. Change un seul caractère et toute la chaîne se brouille en quelque chose de méconnaissable. Parfait pour les checksums sur un fichier de release, les clés de cache, la chasse aux doublons, un payload d'exemple dans ta doc, ce genre de vérification d'intégrité rapide. Du chiffrement, ça n'en est pas. Pas de bouton pour déchiffrer. Pas de clé qui fait marche arrière. Un hash tout seul ne protégera ni un mot de passe ni un bearer token, et je trouve qu'on l'oublie plus souvent qu'on ne veut bien l'admettre.

Je l'ai construit autour de ce que je manipule vraiment dans une semaine normale. MD5 est là pour le jour où un vieux checksum atterrit sur ton bureau. SHA-1 pour les systèmes qui refusent encore de le lâcher. SHA-256, SHA-384 et SHA-512 couvrent tout ce qui est moderne. Tu tapes quelque chose ou tu déposes un petit fichier, tu colles un checksum à comparer, tu choisis hex ou Base64, tu signes avec un secret HMAC. Les notes signalent quelles sorties tu peux coller sans risque dans un document, et lesquelles ne devraient jamais s'approcher d'une vraie décision de sécurité.

Comment choisir un algorithme

Livré à moi-même, je prends SHA-256 quasiment à chaque fois. C'est rapide, personne ne va te chercher des noises là-dessus, et le digest tombe sur une longueur raisonnable. SHA-512, je ne le sors que quand le projet parle déjà en SHA-512, ou quand la chaîne plus longue ne dérange personne. MD5 ? Une seule raison, jamais plus. Un vieil outil m'a refilé un MD5 et je dois le vérifier. Sa résistance aux collisions est morte depuis des années maintenant, alors il reste à des kilomètres de toute nouvelle décision de sécurité. HMAC, c'est une autre bête : tu le sors quand l'autre partie a besoin de la preuve que le message vient de quelqu'un qui détient le secret partagé, pas juste de la preuve que les octets sont arrivés intacts.

MD5 est là pour les vieux checksums et le boulot ingrat de migration. Tiens-le loin de tout ce qui touche à la sécurité.
SHA-1 a lui aussi fait son temps, mais les systèmes plus anciens te le refilent encore, donc tu vas le croiser.
SHA-256 est mon choix par défaut pour tout ce qui est moderne.
HMAC lie un message à un secret. C'est ce que tu veux derrière des webhooks signés ou un exemple d'API vite fait.
Le hachage de fichier prouve sa valeur dès l'instant où tu vérifies une archive téléchargée, ou un export que tu as généré il y a cinq minutes.

Exemples courants de debug de hash

Un éditeur fournit un checksum à côté du téléchargement ? Hashe le fichier, vérifie que ça correspond, et seulement après tu le lances. Jamais l'inverse. Une API signe ses webhooks ? Hashe le corps brut octet par octet, pas le JSON joliment reformaté que ton client HTTP t'a poliment remis en forme. Celle-là, les gens se font avoir tout le temps. Et quand deux payloads ont l'air identiques mais que les digests refusent de s'accorder, c'est une histoire d'espaces neuf fois sur dix. Ou d'encodage. Un CRLF qui traîne, des champs remis dans un ordre différent. Un jour, j'ai perdu presque tout un après-midi à cause d'un seul saut de ligne final, et ça m'agace encore. Les mots de passe, par contre ? Rien de tout ça. Va chercher Argon2, bcrypt ou scrypt et laisse complètement les digests SHA rapides en dehors de tout ça.

Questions fréquentes

Le hachage, c'est pareil que le chiffrement ?

Non. Et l'écart entre les deux fait trébucher pas mal de monde. Le chiffrement, c'est un aller-retour : tu détiens la clé, tu récupères ton original. Le hachage ne va que dans un sens, comme une empreinte que tu ne peux pas dé-presser. Sauf qu'il y a un piège. Si l'entrée est courte ou devinable, rien n'empêche quelqu'un de balancer un tas de candidats dessus jusqu'à ce qu'un digest corresponde.

Pourquoi inclure MD5 s'il est faible ?

Parce que le monde réel est jonché de checksums MD5 que les gens ont publiés il y a des années et n'ont jamais pris la peine de mettre à jour. Tu as quand même besoin de vérifier des choses contre eux. Je le marque comme legacy pour que tu puisses faire exactement ça, sans que personne ne reparte convaincu que MD5 est sûr. Il ne l'est pas.

Quand devrais-je utiliser HMAC ?

Sors HMAC quand tu as besoin de prouver qu'un message vient de quelqu'un qui détient vraiment le secret partagé, pas juste que les octets ont survécu au trajet sans changement. Les signatures de webhook sont le cas classique. Ou un exemple d'API interne vite fait où les deux côtés partagent déjà la clé.

Quel hash devrais-je utiliser pour stocker des mots de passe ?

Aucun de ceux de cette page. Utilise un KDF lent conçu pour ça : bcrypt, scrypt, Argon2. MD5 et toute la famille SHA sont faits pour la vitesse brute, et la vitesse, c'est précisément ce qui offre à un attaquant des milliards de tentatives par seconde. Exactement l'inverse de ce que tu veux ici.

Quelle différence entre un hash et un checksum ?

Un simple checksum comme CRC32 existe pour attraper les accidents. Un bit retourné par un câble capricieux, un téléchargement tronqué à mi-chemin. Un hash cryptographique comme SHA-256 attrape tout ça aussi, mais il tient le coup quand quelqu'un essaie délibérément de te glisser un fichier trafiqué sous le nez. Cette deuxième partie, c'est toute la raison pour laquelle il coûte plus cher à calculer.