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

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 dit si cette chaîne correspond encore à une empreinte publiée. Le HMAC-SHA-256 de la même chaîne, avec un secret partagé, dit si quelqu'un qui connaît le secret l'a produite. Ni l'un ni l'autre n'est un chiffrement, ni un stockage de mot de passe. FastMinify sépare les deux : 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 tournent dans l'onglet via Web Crypto (MD5 est une implémentation locale, car Web Crypto ne le propose pas). Rien n'est envoyé. Les deux sont sur le hub des outils d'encodage, à côté de Base64 et des aides JWT — l'encodage épelle des octets, le hash les empreinte.

Cinq empreintes d'un coup sur la page hash : SHA-256, SHA-384, SHA-512, SHA-1, MD5

HMAC limité à SHA-256, SHA-384 et SHA-512 — pas de mode MD5 ou SHA-1 avec clé

Sortie : hex minuscule ou majuscule, Base64 paddé, ou Base64URL sans padding

Collez une empreinte attendue : 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 (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 — pas un sha256sum binaire

Quand le navigateur est le bon endroit pour hasher

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 contre un test unitaire ou un exemple de doc (abc — la page efface le résultat si le champ est vide ou ne contient que des espaces, donc l'empreinte de la chaîne vide se voit 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 Empreinte attendue et laissez les cinq cartes s'allumer

Montrer l'écart 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 release, conteneurs, images, PDF — sha256sum ou openssl dgst sur le fichier, pas cette page

Fichiers au-delà de 32 Mio, ou extensions hors liste texte — le sélecteur les refuse

Bases de mots de passe — <a href="/fr/bcrypt-hash" class="text-primary hover:underline">bcrypt</a>, pas SHA

Un JWT à accepter ou rejeter — <a href="/fr/jwt-verify" class="text-primary hover:underline">jwt-verify</a>, pas un HMAC bricolé du JSON des claims

Un dépôt qui contient peut-être déjà un secret de signature — <a href="/fr/scan-secrets" class="text-primary hover:underline">scanner les secrets</a> avant de faire tourner 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. C'est ce qu'on veut pour un checksum. Ce n'est pas ce qu'on veut pour un mot de passe : un attaquant précalcule l'empreinte, et deux utilisateurs avec le même mot de passe partagent une ligne. Les docs des pages hash et HMAC le disent. Le stockage de mots de passe va sur bcrypt-hash (ou Argon2 sur votre serveur). HMAC n'est pas non plus le bon outil : il authentifie un message avec un secret à conserver, il n'étire pas un mot de passe.

Stocker SHA-256(mot de passe) et appeler la colonne « hashée »

Utiliser HMAC(mot de passe, poivre) à la place de bcrypt parce que c'est « avec une clé »

Comparer le MD5 d'une passphrase pour décider une connexion

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é ; elle ne prouve 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 : Base64 est un emballage réversible. Le SHA-256 de abc est ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. On ne revient pas de cet hex vers 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 hashant, 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 empreinte du texte UTF-8, pas un fichier brut. L'envoi accepte seulement des extensions texte — txt, md, json, csv, html, xml, yml, yaml — jusqu'au plafond client de 32 Mio, et le fichier est décodé en texte avant le hash. Le SHA-256 fournisseur d'un .tar.gz, d'une image ou d'un PDF ne correspondra pas, et ces types ne sont pas dans le sélecteur. Même un fichier texte peut diverger de sha256sum quand les fins de ligne changent. Le SHA-256 de abc est le vecteur ci-dessus. Le SHA-256 de abc plus un seul LF est edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb. Mêmes lettres, octets différents.

Déposer une archive de release et attendre le checksum fournisseur

Comparer un fichier Windows CRLF avec une empreinte Linux LF

Utiliser <code>echo abc | sha256sum</code> (echo ajoute un saut de ligne) et accuser le navigateur

Renommer un binaire en .txt pour que le sélecteur l'accepte — les octets ne sont plus ceux du fichier

La page est le bon outil pour un extrait, un corps JSON ou une fixture texte. Les artefacts binaires restent sur <code>sha256sum</code> ou <code>openssl dgst</code>.

Signer une autre chaîne que le webhook

Le X-Hub-Signature-256 de GitHub, c'est sha256= plus le HMAC-SHA-256 du corps brut, 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 l'empreinte. 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 <code>sha256=f7bc…</code> dans Empreinte attendue

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 — ces algorithmes sont 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, JWT — 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 ; une empreinte attendue surligne les algorithmes qui correspondent.

Générateur HMAC : secret partagé obligatoire. HMAC-SHA-256 (défaut), SHA-384 ou SHA-512. Message vide ou secret vide : erreur. Pas d'envoi de fichier.

bcrypt-hash : stockage de mot de passe. Lent volontairement. N'envoyez pas une chaîne bcrypt à la page hash en attendant une correspondance.

jwt-verify : contrôle un JWT compact (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 base64url(header).base64url(payload), pas les claims JSON. jwt-verify pour les jetons ; HMAC pour un message brut.

Hex, Base64, Base64URL

Les octets de l'empreinte ne changent pas. L'écriture, si. L'hex est ce que sha256sum et la plupart des docs webhook affichent. Le Base64 paddé est ce que certaines API renvoient. Le Base64URL sans padding est la forme compacte (pas de +, de /, ni de = final). Les majuscules ne s'appliquent qu'à l'hex.

Vecteur NIST, entrée abc, SHA-256 hex : ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad — 64 caractères hex, 32 octets

Même entrée, MD5 hex : 900150983cd24fb0d6963f7d28e17f72 — 32 caractères hex. Checksums hérités seulement ; ne démarrez pas un nouveau protocole sur MD5 ou SHA-1

HMAC-SHA-256, clé les quatre caractères key, message The quick brown fox jumps over the lazy dog, hex : f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8

Le même HMAC en Base64 paddé : 97yD9DBThCSxMpjmqm+xQ+9NWaFJRhdZl0edvC0aPNg= — le Base64URL retire le padding et échange + et / : 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 : 48 octets → 96 hex. SHA-512 : 64 octets → 128 hex. La longueur de sortie HMAC suit le hash choisi

Calculer une empreinte, puis signer un message

Hasher une chaîne ou un fichier texte

Ouvrez le générateur de hash. Collez le texte ou envoyez un fichier texte. Choisissez hex, Base64 ou Base64URL. N'activez les majuscules que si l'empreinte de référence est en capitales — cela ne change rien au Base64. Les cinq algorithmes se rafraîchissent ensemble. Collez l'empreinte attendue pour surligner les correspondances. Chargez l'exemple si vous voulez seulement voir le pipeline. Le champ doit contenir du texte non blanc ; un champ vide efface les cartes au lieu d'afficher le SHA-256 bien connu de la chaîne vide.

Étape 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 réindentez pas le JSON si l'autre côté a hashé la forme compacte.

Étape 2 — Aligner l'écriture de sortie

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

Étape 3 — Coller l'empreinte attendue

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. Pas d'envoi de fichier : collez le message et le secret. Gardez SHA-256 sauf si le fournisseur dit SHA-384 ou SHA-512. Réglez l'encodage de clé sur UTF-8 pour un secret façon passphrase, hex pour une clé hex (préfixe 0x facultatif, longueur paire), ou Base64 si la clé a été stockée ainsi. L'UTF-8 sur un secret hex signe les caractères 0-9a-f, pas les octets de la clé — l'empreinte ne correspond pas et l'erreur n'est pas évidente. L'empreinte attendue suit les mêmes règles que la page hash.

Algorithmes : HMAC-SHA-256 (défaut), SHA-384, SHA-512 — Web Crypto seulement

Message et secret obligatoires ; les valeurs blanches sont rejetées

Sortie : hex, Base64 paddé, 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 — jwt-encode / jwt-verify pour les jetons

Les mêmes octets dans Node et openssl

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

createHash et createHmac empreintent 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 — 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, pas d'envoi vers un serveur, cinq algorithmes de hash ou trois HMAC, hex / Base64 / Base64URL, et un surlignage d'empreinte attendue. Contrepartie : 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 sur l'artefact de release et bcrypt sur le mot de passe.

Conclusion

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

Hasher ou signer dans le navigateur

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 déclarer une empreinte fausse

Fichiers texte seulement dans le navigateur — les binaires restent sur openssl ou sha256sum

Les mots de passe vont vers bcrypt ; les jetons vers jwt-verify

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

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

Quand le navigateur est le bon endroit pour hasher

Les erreurs de hash qui ressemblent à une correspondance

Quel algorithme, quelle écriture, quel outil

Calculer une empreinte, puis signer un message

Étape 1 — Coller les octets exacts comme texte

Étape 2 — Aligner l'écriture de sortie

Étape 3 — Coller l'empreinte attendue

Les mêmes octets dans Node et openssl

Exemple de base

Exemple de base

Conclusion

Articles connexes