Calculateur de hachage de fichier, gratuit

Calculez les hachages SHA-1, SHA-256, SHA-384, SHA-512 et MD5 pour n'importe quel fichier. Vérifiez l'intégrité du fichier et détectez les changements instantanément.

Vos données ne quittent jamais votre appareil
Déposez un fichier ici ou cliquez pour parcourir
Fichier/texte : -
Taille : -
Calculé : -

Ce que sont vraiment les hachages de fichiers

Un hachage cryptographique est une empreinte de longueur fixe calculée à partir de données d'entrée arbitraires (un fichier, une chaîne, un flux d'octets) à l'aide d'une fonction mathématique déterministe. Chaque entrée distincte produit une sortie différente (avec une probabilité de collision infinitésimalement petite pour les fonctions de hachage modernes) ; faire basculer un seul bit n'importe où dans un fichier multi-gigaoctets change essentiellement chaque bit du hachage résultant. La fonction ne fonctionne que dans une direction : à partir de l'entrée vous pouvez calculer le hachage trivialement, mais retrouver l'entrée à partir du hachage est computationnellement infaisable pour toute fonction de hachage décente. La sortie est toujours de la même longueur fixe quelle que soit la taille de l'entrée, SHA-256 produit 256 bits (32 octets, affichés en 64 caractères hex) que l'entrée soit d'un octet ou d'un téraoctet. Trois propriétés comptent : résistance à la préimage (vous ne pouvez pas faire de l'ingénierie inverse d'un fichier à partir de son hachage), résistance à la seconde préimage (vous ne pouvez pas construire un fichier différent avec le même hachage), et résistance aux collisions (vous ne pouvez pas trouver deux fichiers distincts ayant des hachages correspondants). Cet éditeur calcule le hachage de tout fichier que vous fournissez en utilisant la Web Crypto API intégrée au navigateur, spécifiquement SubtleCrypto.digest(), qui est implémentée nativement dans tout navigateur moderne et tourne sur le CPU de l'appareil plutôt que d'uploader le fichier ailleurs.

Les algorithmes, une brève histoire

Cinq algorithmes dans cet outil, par ordre chronologique de sortie. MD5 (Message Digest 5, Ronald Rivest au MIT, RFC 1321 publiée en avril 1992) produit un hachage de 128 bits et fut le hachage généraliste dominant des années 1990 et début 2000. Des faiblesses cryptographiques ont commencé à apparaître en 1996 (pseudo-collision de Dobbertin) ; une attaque par collision pratique a été démontrée par Xiaoyun Wang et Hongbo Yu en août 2004 à CRYPTO 2004, achevée en moins d'une heure sur une seule machine. Marc Stevens a publié une attaque de collision à préfixe choisi en 2008 qui permettait de forger des certificats X.509 en collision. MD5 est désormais cassé pour toute fin cryptographique, ne l'utilisez jamais là où la résistance aux collisions compte (signatures numériques, empreintes de certificat, hachage de mots de passe). Il reste utile pour les vérifications d'intégrité non cryptographiques (détection de corruption accidentelle due à de mauvais disques ou des transferts réseau bruyants) et pour les identifiants adressables par contenu où vous faites confiance à la source de ne pas être malveillante.

SHA-1 (Secure Hash Algorithm 1, conçu par la NSA, publié sous FIPS 180-1 en avril 1995) produit un hachage de 160 bits et fut le hachage cryptographique dominant de la fin des années 1990 jusqu'au début des années 2010. Des attaques théoriques ont été proposées en 2005 par Wang, Yin et Yu. La première collision SHA-1 pratique a été publiée le 23 février 2017 par une équipe Google + CWI Amsterdam dirigée par Marc Stevens (l'attaque « SHAttered ») utilisant environ 9 quintillions de calculs SHA-1 pour produire deux fichiers PDF avec des hachages SHA-1 identiques mais un contenu visiblement différent. Les navigateurs avaient déjà commencé à éliminer progressivement les certificats TLS SHA-1 à ce moment-là ; Git moderne migre de SHA-1 vers SHA-256 pour l'identité des objets. Comme MD5, SHA-1 convient à l'intégrité non cryptographique mais ne devrait jamais être utilisé là où la résistance aux collisions compte en 2026.

SHA-2 (NSA, FIPS 180-2 publié en août 2002) est la famille de hachages de travail actuelle, un ensemble de fonctions associées incluant SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 et SHA-512/256. SHA-256 produit des hachages de 256 bits, SHA-384 des hachages de 384 bits, SHA-512 des hachages de 512 bits ; 384 est essentiellement SHA-512 avec une sortie tronquée et un IV différent. Aucune attaque pratique contre la famille SHA-2 n'existe en 2026 ; SHA-256 est le choix par défaut pour les nouvelles applications et est la fonction de hachage derrière Bitcoin (à la fois pour le minage et la dérivation d'adresses), les empreintes de certificats TLS, la migration prévue d'identité d'objet de Git, le hachage de transaction Ethereum, les signatures JWT HS256, et la plupart des sommes de contrôle de distribution de logiciels. SHA-512 est préféré quand 256 bits de sortie ne suffisent pas ou quand vous voulez la performance légèrement plus rapide sur les CPU 64 bits (les opérations internes de SHA-512 sont sur 64 bits, contre 32 bits pour SHA-256, donc il traite plus de données par cycle CPU sur du matériel 64 bits malgré la sortie plus grande).

SHA-3 (Keccak, conçu par Guido Bertoni, Joan Daemen, Michaël Peeters et Gilles Van Assche, vainqueur du concours NIST SHA-3 en octobre 2012, normalisé en FIPS 202 en août 2015) est la police d'assurance cryptographique : structurellement différent de SHA-2 (construction en éponge plutôt que Merkle-Damgård), de sorte que toute percée qui briserait SHA-2 ne briserait pas nécessairement SHA-3. SHA-3 n'est pas actuellement dans la liste d'algorithmes de cet outil parce que la Web Crypto API ne l'incluait pas dans la spec originale, les navigateurs modernes peuvent l'ajouter à l'avenir. La famille SHA-2 est le défaut recommandé pour le hachage côté navigateur aujourd'hui.

Alternatives modernes au-delà de SHA-2

Deux familles de hachages non-NIST ont gagné en popularité pour des raisons de performance. BLAKE2 (Aumasson, Neves, Wilcox-O'Hearn, Winnerlein, janvier 2013) est plus rapide que SHA-2 avec une sécurité comparable et est largement utilisé en cryptomonnaie, dans le hachage de mots de passe Argon2, et les applications haute performance où la vitesse de SHA-2 est un goulot d'étranglement. BLAKE3 (O'Connor, Aumasson, Neves, Wilcox-O'Hearn, janvier 2020) est une refonte parallélisable sur de nombreux cœurs CPU et encore plus rapide, particulièrement attractive pour hacher de très gros fichiers parce que le travail se répartit proprement entre les cœurs. Aucun n'est dans le standard Web Crypto API, donc cet outil s'en tient à la famille SHA-2 + MD5 + SHA-1 pour la compatibilité ; pour le hachage BLAKE3 en ligne de commande, l'implémentation canonique est l'outil b3sum du dépôt de référence BLAKE3. Le choix pour le hachage de fichiers côté navigateur en 2026 reste SHA-256 sauf raison spécifique d'utiliser autre chose, large compatibilité, pas de problèmes de brevet, accéléré matériellement sur la plupart des CPU modernes (Intel SHA Extensions depuis Goldmont 2016, instructions ARMv8 SHA-2 sur essentiellement chaque smartphone), et vitesse acceptable même sur des fichiers multi-gigaoctets dans le navigateur.

Quand les hachages de fichiers gagnent leur croûte

Comment cet outil fonctionne

Quand vous déposez un fichier dans l'éditeur, le navigateur le lit dans un ArrayBuffer via FileReader.readAsArrayBuffer() (ou, dans les navigateurs modernes, la méthode plus efficace File.arrayBuffer() retournant une Promise). Le crypto.subtle.digest(algorithm, buffer) de la Web Crypto API hache le buffer avec du code natif, implémenté en C++ à l'intérieur du moteur du navigateur, utilisant souvent l'accélération matérielle (Intel SHA Extensions sur x86-64 depuis Goldmont, instructions ARMv8 SHA-2 sur essentiellement chaque smartphone). L'ArrayBuffer retourné est converti en chaîne hex pour l'affichage. Trois hachages JavaScript pur (MD5 et SHA-1, là où la Web Crypto API peut décliner ou là où un polyfill est en usage) tournent via de petites implémentations dédiées. Pas d'étape d'upload, pas de traitement serveur, pas de télémétrie, vérifiez dans l'onglet Réseau des DevTools en déposant un fichier (aucune requête ne part), ou mettez la page hors ligne (mode avion) après son chargement et le hacheur fonctionne toujours sur les fichiers locaux. La limite pratique de taille de fichier est la mémoire du navigateur : hacher un fichier de 1 Go fonctionne mais consomme ~1 Go de RAM pendant l'opération ; les fichiers multi-gigaoctets peuvent forcer le navigateur à swapper ou échouer. Pour les très gros fichiers, un outil dédié en ligne de commande (shasum -a 256 sur macOS/Linux, certutil -hashfile ... SHA256 sur Windows) est le meilleur choix.

Confidentialité : pourquoi le tout-navigateur compte particulièrement ici

Les fichiers que vous pourriez vouloir hacher incluent des logiciels téléchargés (que vous vérifiez pour l'intégrité précisément parce que vous ne leur faites pas encore confiance), des documents privés (dont vous voulez enregistrer le hachage sans les donner à qui que ce soit), des fichiers médias non publiés, des preuves dans une enquête forensique, ou des builds propriétaires où même uploader le fichier vers un service de hachage est inacceptable. Les hacheurs de fichiers côté serveur, même quand ils prétendent « nous ne gardons pas le fichier », reçoivent le contenu entier du fichier, au moment où il est dans leur mémoire, la garantie de confidentialité est partie. Cet outil tourne entièrement dans votre navigateur via la Web Crypto API ; le fichier ne traverse jamais le réseau. Vérifiez dans l'onglet Réseau des DevTools en déposant un fichier (la seule activité réseau devrait être le chargement initial de la page). Mettez la page hors ligne (mode avion) après son chargement (le hacheur fonctionne toujours, prouvant l'architecture locale-uniquement. Pour les fichiers contenant quoi que ce soit de sensible) documents confidentiels, logiciels non publiés, dossiers financiers, scans médicaux, tout ce qui est couvert par un NDA ou une réglementation de conformité, le hachage côté navigateur est la seule option sûre.

Questions fréquentes

Quel algorithme de hachage utiliser ?

SHA-256 est le bon défaut pour tout nouvel usage en 2026, large compatibilité, pas d'attaques pratiques connues, accéléré matériellement sur tout CPU moderne. Utilisez SHA-512 si vous voulez une sortie de 512 bits (légèrement plus rapide sur les CPU 64 bits, plus de bits de résistance aux collisions). Utilisez MD5 ou SHA-1 uniquement quand vous correspondez à une somme de contrôle publiée qui utilise ces algorithmes (certaines distributions Linux publient encore des sommes MD5 à côté de SHA-256 pour la rétrocompatibilité), n'utilisez jamais l'un ou l'autre pour une nouvelle fin cryptographique. Adaptez-vous à l'algorithme que l'éditeur du fichier que vous vérifiez a choisi.

Peut-on inverser un hachage pour retrouver le fichier d'origine ?

Non. Les fonctions de hachage sont délibérément à sens unique, étant donné un hachage, il n'y a pas d'algorithme efficace pour récupérer l'entrée. La seule voie d'attaque est la force brute : hacher des entrées candidates jusqu'à ce qu'une produise un hachage correspondant. Pour des fichiers de toute taille raisonnable (plus de quelques octets) c'est computationnellement infaisable, le nombre de fichiers possibles de même 1 Ko dépasse de plusieurs fois le nombre d'atomes dans l'univers observable. Cette propriété à sens unique est ce qui rend les hachages utiles pour le stockage de mots de passe (avec salage et étirement), les signatures numériques et le stockage adressable par contenu.

MD5 est-il sûr pour la vérification de fichier ?

Pour les vérifications d'intégrité non adversariales (attraper la corruption accidentelle d'un réseau capricieux ou d'un mauvais disque), MD5 convient, des bit flips aléatoires produiront un MD5 différent avec une probabilité écrasante. Pour la vérification adversariale (attraper un acteur malveillant qui a substitué un fichier), MD5 est cassé : les attaques par collision sont pratiques depuis 2004, et les collisions à préfixe choisi depuis 2008. Pratique de sécurité moderne : utiliser SHA-256 pour tout ce où quelqu'un pourrait essayer de vous tromper, et MD5 uniquement quand la source est de confiance et que vous avez juste besoin d'une somme de contrôle rapide.

Y a-t-il une limite de taille de fichier ?

Pas de plafond strict, mais les limites pratiques dépendent de la mémoire du navigateur. Les fichiers jusqu'à quelques centaines de Mo se hachent rapidement sur tout appareil moderne. Les fichiers dans la plage 1-2 Go fonctionnent mais consomment de la RAM égale à la taille du fichier pendant la passe de hachage. Les fichiers multi-gigaoctets peuvent déclencher du swapping ou des crashs OOM du navigateur. Pour les très gros fichiers, les outils en ligne de commande (shasum -a 256 file sur macOS/Linux, certutil -hashfile file SHA256 sur Windows, Get-FileHash dans PowerShell) les gèrent mieux parce qu'ils peuvent streamer le fichier plutôt que de tout charger en mémoire.

Que signifie quand deux fichiers ont le même hachage ?

Pour une fonction de hachage saine (SHA-256, SHA-512, ou n'importe laquelle dans la famille SHA-2 en 2026), cela signifie que les fichiers sont identiques bit pour bit, la probabilité que deux fichiers distincts produisent le même hachage est infinitésimalement petite. Pour les fonctions de hachage cassées (MD5, SHA-1), cela pourrait signifier soit des fichiers identiques soit une collision délibérément construite. Règle pratique : si vous calculez SHA-256 de deux fichiers et obtenez la même valeur, les fichiers sont les mêmes. Si vous calculez MD5 et obtenez la même valeur, les fichiers sont probablement les mêmes mais un adversaire déterminé pourrait les avoir conçus pour entrer en collision.

Outils associés