Générateur de hash et HMAC : MD5, SHA-256, SHA-512 en ligne

Générateur de hash et HMAC : MD5, SHA-256, SHA-512 en ligne

Calculez MD5, SHA ou un HMAC dans le navigateur. Hex, Base64 ou Base64URL — checksum de texte et signature de webhook, 100 % local.

21.09.2026
12 min de lecture
Partager cet article:
HashHMACSHA-256ChecksumSécuritéTutoriel

Une empreinte prouve les octets ; HMAC prouve qui les a envoyés

Un hash et un HMAC ne répondent pas à la même question. Le SHA-256 d'une chaîne indique si cette chaîne correspond encore à une empreinte publiée. Le HMAC-SHA-256 de la même chaîne, calculé avec un secret partagé, indique si quelqu'un qui connaît le secret l'a produite. Ni l'un ni l'autre n'est un chiffrement ou un stockage de mots de passe. FastMinify sépare les deux usages. Le générateur de hash en ligne calcule MD5, SHA-1, SHA-256, SHA-384 et SHA-512 sur du texte UTF-8, et le générateur HMAC signe un message en HMAC-SHA-256, SHA-384 ou SHA-512. Les deux fonctionnent dans l'onglet du navigateur grâce à Web Crypto (MD5 est une implémentation locale, car Web Crypto ne le propose pas), et rien n'est envoyé. Les deux figurent sur le hub des outils d'encodage, à côté de Base64 et des outils JWT. L'encodage épelle des octets, le hachage en prend l'empreinte.

Cinq empreintes à la fois sur la page hash : SHA-256, SHA-384, SHA-512, SHA-1, MD5
HMAC limité à SHA-256, SHA-384 et SHA-512, sans mode MD5 ou SHA-1 avec clé
Sortie : hex en minuscules ou en majuscules, Base64 avec padding ou Base64URL sans padding
Collez un digest attendu : les algorithmes correspondants sont surlignés ; la casse hex, les espaces et le padding Base64URL sont ignorés
Encodage de la clé HMAC : texte UTF-8 (par défaut), octets hex ou octets Base64 / Base64URL
La page hash accepte un fichier texte (txt, md, json, csv, html, xml, yml, yaml) jusqu'à 32 Mio, lu en UTF-8 : elle ne remplace pas sha256sum pour les fichiers binaires

Quand le navigateur est le bon endroit pour hacher

Bons usages

Une chaîne que vous pouvez coller, un secret que vous acceptez de taper dans votre propre navigateur, une empreinte que vous avez déjà.

Vérifier le SHA-256 d'une courte fixture avec un test unitaire ou un exemple de documentation comme abc. Un champ vide efface le résultat : l'empreinte de la chaîne vide se lit dans un REPL, pas dans l'outil
Comparer un corps JSON ou YAML que vous venez d'éditer avec l'empreinte envoyée par un collègue, après accord sur LF ou CRLF
Reproduire un HMAC façon GitHub du corps brut, puis comparer l'hex sans le préfixe sha256=
Voir à quel algorithme appartient un hex inconnu : collez-le dans Digest attendu et laissez les cinq cartes s'allumer
Montrer la différence entre Base64, un hash et HMAC sans installer Node
Laissez ça à la machine qui détient le fichier ou la clé

Si les octets sont un artefact binaire, ou si le secret ne doit pas apparaître dans un navigateur sur une machine partagée, restez dans le shell ou en CI.

Archives de version, conteneurs, images et PDF : sha256sum ou openssl dgst sur le fichier, pas cette page
Fichiers de plus de 32 Mio ou à extension hors de la liste texte, que le sélecteur refuse
Bases de mots de passe : bcrypt, pas SHA
Un JWT à accepter ou à rejeter : jwt-verify, pas un HMAC bricolé du JSON des claims
Un dépôt qui contient peut-être déjà un secret de signature : scanner les secrets avant de renouveler la clé que vous venez de coller

Les erreurs de hash qui ressemblent à une correspondance

Utiliser SHA ou MD5 comme hash de mot de passe

Une empreinte simple est rapide, sans sel et identique pour la même entrée. Cela convient à un checksum, pas à un mot de passe : un attaquant peut calculer l'empreinte à l'avance, et deux utilisateurs avec le même mot de passe partagent la même valeur. La documentation des pages hash et HMAC le rappelle. Les mots de passe relèvent de bcrypt-hash (ou d'Argon2 sur votre serveur). HMAC n'est pas non plus le bon outil, car il authentifie un message avec un secret à conserver et n'étire pas un mot de passe.

Stocker SHA-256(mot de passe) et appeler la colonne « hachée »
Utiliser HMAC(mot de passe, poivre) à la place de bcrypt parce que c'est « avec une clé »
Autoriser une connexion en comparant le MD5 d'une passphrase
Croire qu'une empreinte plus longue (SHA-512) remplace le sel et le facteur de coût
Checksums et signatures de webhook ici. Mots de passe sur bcrypt, avec un coût que votre serveur peut assumer.
Prendre un hash pour une signature, ou Base64 pour un hash

N'importe qui peut recalculer le SHA-256 d'un corps public. L'empreinte prouve que le corps n'a pas changé, mais pas qui l'a produit. Si un webhook, une note de version ou un appel d'API doit être authentique, il faut un secret : HMAC, ou une signature JWT vérifiée avec jwt-verify. La confusion inverse est tout aussi courante après le guide Base64 encoder et décoder, car Base64 est un emballage réversible. Le SHA-256 de abc est ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. On ne revient pas de cet hex à abc.

Publier un SHA-256 à côté d'un corps JSON et dire que le corps est signé
Décoder une empreinte avec l'outil Base64 en espérant le texte d'origine
Coller un JWT dans le générateur de hash pour voir s'il est valide
Masquer une clé d'API en la hachant, puis ne plus pouvoir la retrouver alors que le serveur en a besoin
Intégrité sans secret → hash. Intégrité avec secret partagé → HMAC. Confidentialité → chiffrement, que ces pages ne font pas. Épellation réversible → Base64.
Checksum d'un fichier qui n'est pas les octets sur le disque

Le générateur de hash calcule l'empreinte de texte UTF-8, pas d'un fichier brut. Le sélecteur de fichiers n'accepte que des extensions de texte (txt, md, json, csv, html, xml, yml, yaml), dans la limite de 32 Mio du navigateur. Le fichier est décodé en texte avant le calcul. Le SHA-256 publié par un éditeur pour un .tar.gz, une image ou un PDF ne correspondra pas, et ces types ne figurent pas dans le sélecteur. Même un fichier texte peut différer de sha256sum quand les fins de ligne changent. Le SHA-256 de abc est le vecteur ci-dessus. Celui de abc suivi d'un seul LF est edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb. Mêmes lettres, octets différents.

Déposer une archive de version et attendre le checksum de l'éditeur
Comparer un fichier Windows CRLF avec une empreinte Linux LF
Utiliser echo abc | sha256sum (echo ajoute un saut de ligne) et accuser le navigateur
Renommer un binaire en .txt pour que le sélecteur l'accepte, alors que le décodage en texte modifie ses octets
La page est le bon outil pour un extrait, un corps JSON ou une fixture texte. Les artefacts binaires restent sur sha256sum ou openssl dgst.
Signer une autre chaîne que le webhook

Le X-Hub-Signature-256 de GitHub est sha256= suivi du HMAC-SHA-256 du corps brut, avec le secret en UTF-8. Stripe signe timestamp.payload, pas le JSON seul. La page HMAC ne construit pas ces chaînes et ne retire pas un préfixe sha256=. Collez le message exact, les octets exacts de la clé, et seulement le digest. La comparaison ignore la casse hex et les espaces, ainsi que le = final en Base64URL. Elle n'ignore pas un préfixe.

Coller tout l'en-tête sha256=f7bc… dans Digest attendu
Réindenter le JSON avant de signer : les espaces changent le HMAC
Laisser l'encodage de clé sur UTF-8 alors que le secret est une clé hex ou Base64
Demander un HMAC MD5 ou SHA-1, des algorithmes réservés à la page hash
Reproduisez l'entrée exacte du fournisseur. Si la signature manque encore, le bug est dans les octets fournis, pas dans un second algorithme.

Quel algorithme, quelle écriture, quel outil

Hash, HMAC, bcrypt et JWT sont quatre verrous différents

Ils produisent tous des chaînes opaques. Ils ne se remplacent pas.

Générateur de hash : pas de secret. MD5, SHA-1, SHA-256, SHA-384, SHA-512 d'un texte UTF-8. Les cinq se mettent à jour ensemble ; un digest attendu surligne les algorithmes qui correspondent.
Générateur HMAC : secret partagé obligatoire. HMAC-SHA-256 (par défaut), SHA-384 ou SHA-512. Un message vide ou un secret vide est une erreur. Pas d'envoi de fichier.
bcrypt-hash : stockage de mot de passe. Lent volontairement. Ne collez pas une chaîne bcrypt dans la page hash en espérant une correspondance.
jwt-verify : contrôle un JWT compact, de la forme header.payload.signature, contre une clé ou un JWKS. HMAC-SHA-256 est la primitive derrière HS256, mais l'entrée signée est formée des deux parties Base64URL reliées par un point, pas des claims JSON. Utilisez jwt-verify pour les jetons et HMAC pour un message brut.
Hex, Base64, Base64URL

Les octets du digest ne changent pas. L'écriture, si. L'hex est la forme affichée par sha256sum et par la plupart des documentations de webhook. Le Base64 avec padding correspond à ce que renvoient certaines API. Le Base64URL sans padding est la forme compacte (pas de +, de /, ni de = final). Les majuscules ne s'appliquent qu'à l'hex.

Vecteur NIST pour l'entrée abc, SHA-256 en hex : ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad (64 caractères hex, 32 octets)
Même entrée, MD5 en hex : 900150983cd24fb0d6963f7d28e17f72 (32 caractères hex). Checksums hérités seulement ; ne construisez pas de nouveau protocole sur MD5 ou SHA-1
HMAC-SHA-256 avec la clé de quatre caractères key et le message The quick brown fox jumps over the lazy dog, en hex : f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
Le même HMAC en Base64 avec padding s'écrit 97yD9DBThCSxMpjmqm+xQ+9NWaFJRhdZl0edvC0aPNg=. Le Base64URL retire le padding et remplace le plus et la barre oblique par un tiret et un tiret bas, ce qui donne 97yD9DBThCSxMpjmqm-xQ-9NWaFJRhdZl0edvC0aPNg
Des longueurs à compter avant de faire confiance à un collage

Une empreinte tronquée est une copie ratée, pas un autre algorithme. Comptez les caractères après avoir retiré les espaces.

MD5 : 16 octets → 32 hex, ou 24 caractères Base64 avec padding
SHA-1 : 20 octets → 40 hex. Des collisions existent ; gardez-le pour les manifestes hérités seulement
SHA-256 : 32 octets → 64 hex, 44 Base64 avec un =, 43 Base64URL sans padding
SHA-384 et SHA-512 donnent 48 et 64 octets, soit 96 et 128 caractères hex. La longueur de sortie HMAC suit le hash choisi

Calculer une empreinte, puis signer un message

Hacher une chaîne ou un fichier texte

Ouvrez le générateur de hash. Collez le texte ou choisissez un fichier texte. Choisissez hex, Base64 ou Base64URL. N'activez Hex majuscules que si le digest de référence est écrit en capitales, car l'option ne change rien au Base64. Les cinq algorithmes se mettent à jour ensemble. Collez le digest attendu pour surligner les correspondances, ou chargez l'exemple si vous voulez seulement voir le fonctionnement. Le champ doit contenir autre chose que des espaces : un champ vide efface les cartes au lieu d'afficher le SHA-256 bien connu de la chaîne vide.

1

1. Coller les octets exacts comme texte

Mettez-vous d'accord sur les sauts de ligne. Un LF final fait partie de l'entrée. Ne changez pas l'indentation du JSON si l'autre côté a haché la forme compacte.

2

2. Aligner l'écriture de sortie

Hex pour les checksums et les outils CLI. Base64 avec padding quand l'API montre + / et =. Base64URL sans padding quand l'empreinte va dans un jeton ou une URL.

3

3. Coller le digest attendu

La comparaison ignore la casse hex et les espaces, ainsi que le padding Base64URL. Une correspondance surligne l'algorithme. Aucun surlignage : octets différents, écriture différente, ou préfixe encore à retirer.

Signer avec HMAC

Ouvrez le générateur HMAC. Il n'y a pas de sélection de fichier, donc collez le message et le secret. Gardez SHA-256, sauf si le fournisseur indique SHA-384 ou SHA-512. Réglez Encodage de la clé sur UTF-8 pour un secret de type passphrase, sur hex pour une clé hex (préfixe 0x facultatif, longueur paire), ou sur Base64 ou Base64URL si la clé a été stockée ainsi. Avec UTF-8 sur un secret hex, la page signe les caractères 0-9a-f et non les octets de la clé : le digest ne correspond pas, et la cause n'est pas évidente. Le Digest attendu suit les mêmes règles de comparaison que la page hash.

Algorithmes : HMAC-SHA-256 (par défaut), SHA-384, SHA-512, tous via Web Crypto
Message et secret obligatoires ; les valeurs ne contenant que des espaces sont rejetées
Sortie : hex, Base64 avec padding, Base64URL sans padding ; les majuscules ne concernent que l'hex
Le secret reste dans l'onglet. Fermez-le ensuite ; la page n'est pas un coffre
L'entrée signée d'un JWT HS256 n'est pas l'objet des claims : utilisez jwt-encode / jwt-verify pour les jetons

Les mêmes octets dans Node et openssl

Node crypto en UTF-8, sans saut de ligne ajouté

createHash et createHmac calculent l'empreinte de la chaîne que vous passez. Ils n'ajoutent pas de saut de ligne. Cela correspond aux outils du navigateur.

Exemple de base

const crypto = require('node:crypto') const sha256 = crypto.createHash('sha256').update('abc').digest('hex') // ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad const hmac = crypto.createHmac('sha256', 'key') .update('The quick brown fox jumps over the lazy dog') .digest('hex') // f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
openssl avec printf, pas echo

echo ajoute un saut de ligne, donc l'empreinte porte sur d'autres octets. printf non. Pour un fichier sur disque, ne passez -binary que si vous voulez les octets bruts de l'empreinte ; l'hex est la forme texte par défaut.

Exemple de base

printf 'abc' | openssl dgst -sha256 # ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad printf 'The quick brown fox jumps over the lazy dog' | openssl dgst -sha256 -hmac key # f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8 # artefact binaire — pas l'outil du navigateur openssl dgst -sha256 release.tar.gz
FastMinify hash-generator / hmac-generator

Pas d'installation, rien n'est envoyé à un serveur, cinq algorithmes de hash ou trois HMAC, hex / Base64 / Base64URL, et un surlignage du digest attendu. Les limites : texte et UTF-8 seulement, plafond de 32 Mio pour un fichier texte sur la page hash, pas de checksum binaire, pas de HMAC-MD5, pas d'étirement de mot de passe, pas d'assemblage JWT. Utilisez les pages pour inspecter un extrait ou reproduire une signature de webhook. Gardez openssl pour l'artefact livré et bcrypt pour le mot de passe.

Conclusion

Hachez le texte quand vous devez savoir qu'il n'a pas changé. Utilisez HMAC quand un secret partagé doit prouver qui l'a produit. FastMinify fait les deux dans le navigateur. L'outil gère MD5 jusqu'à SHA-512 pour du texte UTF-8 (et des fichiers texte jusqu'à 32 Mio), ainsi que HMAC-SHA-256, SHA-384 ou SHA-512 avec une clé UTF-8, hex ou Base64, écrite en hex, Base64 ou Base64URL sans padding. Il ne calcule pas le checksum d'une archive, ne stocke pas de mot de passe et ne vérifie pas de JWT. Ces tâches restent à openssl, bcrypt et jwt-verify. Partez du hub des outils d'encodage tant que la chaîne n'est encore que du texte.

SHA-256 pour les nouveaux checksums ; MD5 et SHA-1 seulement si un manifeste hérité l'exige
HMAC dès qu'il y a un secret partagé ; un hash nu n'authentifie pas l'expéditeur
Alignez sauts de ligne et écriture (hex, Base64, Base64URL) avant de conclure qu'une empreinte est fausse
Fichiers texte seulement dans le navigateur ; les binaires restent à openssl ou sha256sum
Les mots de passe vont vers bcrypt ; les jetons vers jwt-verify
Partager cet article
Partager cet article: