Vai al contenuto
Hash e checksum

Calcolo hash da testo o file

Diciotto algoritmi calcolati in parallelo direttamente nel browser, raggruppati per famiglia: SHA-2 (256, 384, 512), SHA-3 (224, 256, 384, 512), BLAKE2b/2s, RIPEMD-160, CRC-32 e CRC-16/CCITT per i checksum di integrità, MurmurHash3 e xxHash32 per il fingerprinting non crittografico, MD5 e SHA-1 per i casi legacy. Input testo (UTF-8) o file fino a 100 MB. Export CSV per documentare i checksum di una serie di file.

Testo

File

Trascina un file qui, oppure click per sceglierlo

Massimo 100 MB. Il file resta sul tuo computer.

Risultati

Algoritmo Hash (esadecimale) Dimensione

Come si usa

  1. 1

    Scegli la sorgente

    Incolla il testo nella casella a sinistra oppure trascina un file nella zona a destra. Il file resta sul tuo computer: niente upload, niente trasferimento.

  2. 2

    Calcola

    I diciotto algoritmi vengono calcolati in parallelo. Per il testo puoi tenere attiva l'opzione "Calcola mentre scrivi" e vedere gli hash aggiornarsi a ogni modifica. Per un file da 100 MB il calcolo completo dura tipicamente sotto i 2-3 secondi su un computer moderno.

  3. 3

    Verifica un download

    Per controllare l'integrità di un file scaricato, confronta l'hash nella riga della famiglia indicata dal sito (di solito SHA-256) con quello pubblicato sul sito di origine. Click su "Copia" nella riga interessata per copiare il valore esadecimale.

  4. 4

    Esporta in CSV

    Per documentare i checksum di più file (backup, asset distribuiti, deliverable di progetto), processa ogni file e usa "Esporta CSV". Ottieni un file con colonne family,algorithm,hash,bytes,source riusabile in pipeline o conservato come manifest.

Perché farlo nel browser

Il file resta sul tuo computer. Backup di database, dump di configurazione, certificati, archivi privati: l'hash di un file è già una sua impronta univoca, e calcolarlo su un servizio terzo equivale a inviargli quell'impronta. Qui il calcolo avviene direttamente nel tab del browser, senza alcun trasferimento esterno. Verificabile dal pannello Network degli strumenti per sviluppatori: aprilo, trascina un file, e vedrai zero richieste di rete uscire mentre l'hash viene calcolato.

Diciotto algoritmi in un colpo solo. Le famiglie sono separate visivamente nella tabella: SHA-2 e SHA-3 per uso crittografico generale, BLAKE2 per checksum moderni veloci (utilizzati ad esempio nelle ISO Linux moderne), RIPEMD-160 per indirizzi Bitcoin e firme legacy, CRC-32 per archivi ZIP e PNG, MurmurHash3 e xxHash per casi non crittografici tipo deduplicazione e cache. MD5 e SHA-1 sono mostrati con un badge "legacy" e restano disponibili per casi di compatibilità con sistemi vecchi.

File grandi: meglio la riga di comando. Il limite di 100 MB tiene il tab reattivo senza spinner. Per file molto più grandi (ISO da 4 GB, dump di database da decine di GB) gli strumenti da riga di comando sono più efficienti perché leggono il file a chunk e mostrano un progress nativo: sha256sum file.iso su Linux e macOS, certutil -hashfile file.iso SHA256 su Windows, Get-FileHash file.iso -Algorithm SHA256 in PowerShell.

Glossario

Termini tecnici usati in questa pagina, spiegati in due righe.

Hash crittografico #
Funzione che mappa un input di dimensione qualsiasi su un output di lunghezza fissa, in modo che cambiare anche un solo bit dell'input produca un output completamente diverso e che sia computazionalmente non praticabile risalire all'input dall'output o trovare due input con lo stesso output.
Famiglia SHA-2 #
Standard NIST FIPS 180-4: comprende SHA-224, SHA-256, SHA-384, SHA-512. SHA-256 è oggi lo standard di fatto per integrità di file e firme digitali. Considerato sicuro per uso crittografico generale.
Famiglia SHA-3 #
Standard NIST FIPS 202 (2015), basato sulla costruzione Keccak. Disegnato come alternativa a SHA-2 in caso quest'ultima venga rotta. Entrambi sono oggi considerati sicuri.
BLAKE2 #
Famiglia di hash moderni (RFC 7693) con due varianti: BLAKE2b ottimizzata per CPU 64-bit, BLAKE2s per 32-bit e ambienti embedded. Più veloce di SHA-256 a parità di sicurezza. Adottata da numerosi sistemi moderni come funzione di checksum di default.
RIPEMD-160 #
Hash a 160 bit (ISO/IEC 10118-3) progettato in Europa come alternativa a SHA-1. Usato negli indirizzi Bitcoin (in combinazione con SHA-256) e in alcune firme legacy GnuPG.
CRC-32 / CRC-16 #
Cyclic Redundancy Check: non sono hash crittografici, ma codici di rilevazione di errori. Usati per verificare l'integrità di archivi ZIP, immagini PNG, frame Ethernet, protocolli seriali. Veloci ma facilmente forgiabili: non offrono alcuna protezione contro manomissione intenzionale.
MurmurHash3 / xxHash #
Hash non crittografici progettati per essere estremamente veloci. Usati nelle hash table, nei sistemi di deduplicazione, nei bucket assignment di cache distribuite. Non offrono resistenza alle collisioni in senso crittografico: pensali come fingerprint veloci, non come prove di integrità.
Collisione #
Due input diversi che producono lo stesso hash. Per un hash a N bit una collisione casuale è attesa dopo circa 2^(N/2) tentativi (paradosso del compleanno). Per gli hash rotti come MD5 e SHA-1 esistono attacchi che producono collisioni in tempi molto più brevi del limite teorico.
Hash esadecimale #
Convenzione di output: ogni byte raw del digest viene scritto come due caratteri esadecimali minuscoli. MD5 produce 16 byte = 32 caratteri, SHA-256 produce 32 byte = 64 caratteri, SHA-512 produce 64 byte = 128 caratteri.

Domande frequenti

Posso davvero fidarmi che il file non venga caricato da qualche parte?
Sì, ed è verificabile in due click. Apri gli strumenti per sviluppatori del browser (F12 nella maggior parte dei casi), vai sul pannello Network e inizia a registrare. Trascina un file nella zona di drop e calcola gli hash. Vedrai zero richieste HTTP uscire dal browser durante il calcolo. Tutta la lettura del file e il calcolo degli hash avvengono nel tab, senza coinvolgere la rete.
Perché MD5 e SHA-1 sono marcati come algoritmi legacy?
Per MD5 la prima collisione completa è stata pubblicata nel 2004 da Wang, Feng, Lai e Yu, e nel 2008 Stevens e altri hanno costruito due certificati X.509 con hash MD5 identico. Da allora produrre una collisione MD5 è alla portata di un laptop. Per SHA-1 la prima collisione pratica è stata dimostrata da Google nel 2017 con il progetto SHAttered. Nel 2020 Leurent e Peyrin hanno pubblicato "SHA-1 is a Shambles", una collisione del tipo più pericoloso (chosen-prefix) ottenibile per circa 45.000 dollari di tempo GPU in noleggio: a quel punto tutti gli attacchi che erano pratici su MD5 sono diventati pratici anche su SHA-1. La conseguenza è che entrambi non offrono più la garanzia che era alla base della loro adozione, e gli usi che dipendono da quella garanzia (firme, autenticazione di download contro un avversario, certificati) devono usare SHA-256 o superiore.
Quindi sono ufficialmente deprecati?
Sì, da enti di standardizzazione diversi e con tempi diversi. L'IETF ha pubblicato RFC 6151 nel 2011 dichiarando che MD5 "non deve essere usato" dove serve resistenza alle collisioni e che le nuove specifiche non devono adottarlo. NIST ha annunciato il ritiro ufficiale di SHA-1 il 15 dicembre 2022 e ha fissato la deadline di transizione al 31 dicembre 2030 per i moduli crittografici certificati FIPS. La bozza pubblica di NIST SP 800-131A Rev. 3 (ottobre 2024) formalizza il calendario di ritiro anche per gli hash a 224 bit e per altri primitivi datati. In pratica, dal 2030 i moduli crittografici certificati non potranno più usare SHA-1 per scopi che richiedono resistenza alle collisioni.
Allora perché lasciarli nel tool?
Perché esistono ancora casi legittimi: verificare l'integrità di un download contro la corruzione accidentale (no avversario), confrontare l'hash di un file con un manifest storico, leggere checksum pubblicati anni fa, lavorare con sistemi legacy che li usano internamente per identificatori non security-critical. Restano nella tabella, in fondo e con un badge esplicito, perché chi ha bisogno di calcolarli abbia uno strumento, e chi non li conosce a fondo veda subito che si trovano in una categoria a parte.
Perché BLAKE3, Whirlpool e Tiger non sono inclusi?
BLAKE3 in versione corretta richiede una struttura a Merkle parallela: le implementazioni mature sono compilate, e per coerenza con il resto di questo dominio (tutto in JavaScript ispezionabile dal browser) preferiamo non includerlo finché non c'è una versione pure-JS auditabile a costo accettabile. Whirlpool e Tiger sono algoritmi ormai di nicchia, usati quasi esclusivamente in contesti legacy specifici (Direct Connect, Gnutella, alcuni progetti accademici): se servono, gli strumenti dedicati a riga di comando li gestiscono già.
E password hashing? Posso usare questo tool per hashare password?
No, nessuno degli algoritmi presenti è adatto. Per le password servono funzioni progettate apposta per essere lente e per richiedere molta memoria: argon2id (raccomandazione 2026), bcrypt (legacy ma ancora valido), scrypt. Vivono lato server, applicate a un input strutturato (con salt univoco per utente). Un tool web di calcolo hash non è il posto giusto: in produzione vanno integrate nel sistema di autenticazione, non calcolate manualmente.
Il mio file è da 500 MB, come faccio?
Usa la riga di comando, è più efficiente perché legge il file a chunk con progress nativo. Su Linux o macOS: sha256sum file.iso oppure shasum -a 256 file.iso. Su Windows in cmd.exe: certutil -hashfile file.iso SHA256. In PowerShell: Get-FileHash file.iso -Algorithm SHA256. Per BLAKE2 su Linux: b2sum file.iso.
Perché lo stesso file mi dà hash diversi tra il browser e la riga di comando?
Per file binari (immagini, archivi, ISO, eseguibili) gli hash sono bit-per-bit identici. Quando vedi differenze su input testuali, di solito il colpevole è uno tra: line ending diversi (CR/LF/CRLF), un carattere di nuova riga aggiunto in coda dalla shell (echo "text" | sha256sum aggiunge un \n), un BOM UTF-8 presente in un file e non nell'altro. Per il calcolo di hash su testo ricordati di confrontare lo stesso identico flusso di byte.
Cosa significa la dimensione (16 B, 32 B, 64 B)?
È la lunghezza dell'output in byte raw, prima della codifica esadecimale. MD5 produce 16 byte (32 caratteri esadecimali), SHA-256 produce 32 byte (64 caratteri), SHA-512 produce 64 byte (128 caratteri). La codifica esadecimale raddoppia la lunghezza testuale per rendere l'output leggibile e copiabile come stringa.
Funziona offline?
Sì. Una volta caricata la pagina puoi disconnettere la rete: il calcolo continua a funzionare. Tutti i diciotto algoritmi vivono nel browser, nessuna API esterna viene chiamata.
Gli hash che produco qui sono compatibili con quelli di sha256sum o di OpenSSL?
Sì, byte per byte. Le implementazioni passano i vettori di test ufficiali RFC e NIST: SHA-256 prodotto qui coincide con sha256sum, OpenSSL EVP_sha256, Python hashlib.sha256. SHA-3 coincide con openssl dgst -sha3-256. BLAKE2b coincide con b2sum. Se vedi differenze, è quasi certamente un problema di encoding o line ending nell'input.

Chi sviluppa questi strumenti?

Maurizio Fonte, consulente IT senior con oltre 20 anni di esperienza in PHP, Laravel, infrastrutture Linux, cybersecurity e integrazione AI/LLM in azienda. Backend di produzione, modernizzazione di codice legacy, audit di sicurezza, agenti AI e MCP server custom: il lavoro che sta dietro a questi strumenti.

Conosci Maurizio Fonte