How to hash text or a file
There is no separate Hash button. The page hashes whichever source is selected, and it replaces all four digests when that source changes. Text and File are tabs, not two inputs that get combined.
- Choose Text or File. Only the selected tab is hashed. The other tab keeps what you entered, and it comes back into the digest when you select it again.
- On Text, type or paste. The note under the field says “Hashed as UTF-8 bytes. Spaces and line breaks count.”
- On File, select one file. The page shows its name and size, then reads it. The note says “Up to 32 MiB. Empty files are supported.” The picker takes a single file of any type.
- Read the four rows. Press Copy for one digest, or Copy all for the set. If you already have a checksum, paste the hexadecimal value into Compare.
Text is hashed about 180 milliseconds after you stop typing, so the rows are not rebuilt on every key. The status line reads “Updating…”, then “Calculating hashes…”, then “Four digests ready”. An empty text field is not hashed. The status stays “Enter text or choose a file”, SHA-256 reads “Awaiting input”, and the other three rows show a dash. A field that contains only spaces is not empty. Those spaces are hashed.
While an input method is still composing a character, the page clears the digests and waits. Hashing runs after the composition ends, on the finished text. That is why the rows can go blank in the middle of a word and fill in again once the character is confirmed.
The tabs are a keyboard tab list. Left and right arrows move between Text and File. Home and End jump to the first and last tab. Switching tabs clears the current digests first. An empty text field then waits. A file that is already chosen is read again.
If you change the text or pick another file before a slow read finishes, the late result is thrown away. The rows follow the latest source, not an earlier one that was still in flight.
Text and files are not the same bytes
The text field is turned into UTF-8 bytes, and all four algorithms hash those bytes. The script does not trim the field, and it does not convert the text to another Unicode form. A leading space, a trailing space, and a blank line are part of the input. “Abc” and “abc” differ. So do “abc” and “abc ” with a space on the end.
The expected-checksum box is the field that trims. It strips spaces and line breaks from the ends of a pasted digest, then checks the length. The text you are hashing is not trimmed. Treating those two boxes as the same is a common reason a short string “does not match” a digest from somewhere else.
Line breaks are the next place copies drift apart. An HTML text box stores a line break as one line feed, LF. Paste Windows-style CRLF and the box has already turned each pair into a single LF before this page reads the field. The hasher does not undo that, and it does not add a byte-order mark. File is the raw bytes on disk. Those bytes can include CR, a UTF-8 BOM (the three bytes EF BB BF), and a final newline an editor saved even though you did not type one. The same characters can produce one digest from Text and another from File. Both answers are the bytes that source actually held.
A fixed example makes the newline visible. The three letters abc, and nothing else, have this SHA-256:
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
The same three letters followed by one LF line break have this SHA-256:
edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb
A file of those letters saved with CRLF, which you will only see on the File tab, has this SHA-256:
552bab6864c7a7b69a502ed1854b9245c0e1a30f008aaa0b281da62585fdb025
None of these is the hash of the word in the abstract. Each one is the hash of a different byte string. When a digest disagrees, compare the bytes, not the letters on the screen. Encoding is the same kind of trap. A file saved as UTF-16, or as an older one-byte encoding, will not match UTF-8 of the same characters. This page does not ask you to pick an encoding. Text is UTF-8. A file is whatever bytes you selected.
Accented letters can split the same way. The single character é and the two-code-point sequence of e plus a combining accent are different UTF-8 sequences. This page does not normalize them into one form. A tool that does will print another digest. Paste the exact text, or hash the file, instead of retyping it from memory.
An empty file is a real input. Zero bytes have one fixed digest per algorithm. An empty text field is not that input: it waits, and it does not show the values below. Select a zero-byte file to see them. The size is shown as 0 B.
- MD5 · 32 hex characters
d41d8cd98f00b204e9800998ecf8427e- SHA-1 · 40 hex characters
da39a3ee5e6b4b0d3255bfef95601890afd80709- SHA-256 · 64 hex characters
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855- SHA-512 · 128 hex characters
cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e
Those four strings are the whole lower-hex result for a zero-byte file. They are a sanity check that the file you selected was actually empty, and that the display is lowercase hex. They are not the hash of a blank line. A blank line is a line break, and a line break is not zero bytes.
Four digests, three ways to write them
Every successful run fills the same four rows, from the same bytes. SHA-256 is marked Recommended. SHA-1 and MD5 are marked Legacy. SHA-512 has no extra label. The footnote under the rows is the rule for the legacy pair: “MD5 and SHA-1 are for matching older checksums, not security-sensitive verification.”
- SHA-256 · 32 bytes
- 64 hex characters. The row to copy when you publish a new checksum, and the row most download pages print today.
- SHA-512 · 64 bytes
- 128 hex characters. The other modern SHA-2 digest on this page. Use it when the other party printed SHA-512. The page does not claim it is faster in the browser.
- SHA-1 · 20 bytes
- 40 hex characters. Legacy, so you can match an older published checksum.
- MD5 · 16 bytes
- 32 hex characters. Legacy, for the same reason.
The page always calculates all four. There is no switch to turn one off. There is no SHA-384, SHA-3, BLAKE, or CRC. You do not pick an algorithm and then hash. You hash once and read the row that matches the checksum you were given.
The format control only changes how those bytes are written. It does not hash again. “lower hex” is selected when the page loads: digits and a–f, with no spaces and no colons. “UPPER HEX” is the same hex in capitals. “Base64” uses the standard alphabet, including +, /, and = padding when the length needs it. Copy and Copy all follow whichever format is pressed. The buttons stay disabled until a result exists.
Copy all writes four lines, in a fixed order, each with the algorithm name, a colon, a space, and the digest in the current format:
SHA-256: …
SHA-512: …
SHA-1: …
MD5: …
A successful copy changes that button’s label to “Copied” for just under two seconds, then puts back “Copy” or “Copy all”. If the browser blocks the clipboard, the message is “Copy failed. Select and copy the digest manually.” The page does not clear the clipboard afterwards. The value stays until some other copy replaces it. If you change the format after copying, copy again. The clipboard still holds the previous format.
SHA-256, SHA-512, and SHA-1 come from the browser’s Web Crypto call crypto.subtle.digest. MD5 is not part of Web Crypto, so MD5 comes from the bundled spark-md5 library. The four rows still describe one input. If Web Crypto cannot run, you do not get an MD5-only fallback. The page shows an error instead of a partial set: “Could not calculate the hashes in this browser. Try a smaller file or another browser.” The status line reads “Hashing failed”.
Base64 is another way to write the same digest, not a different hash. The zero-byte SHA-256 in Base64 is 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=. The + and the trailing = are why that string is rejected by Compare. Compare accepts hexadecimal only.
Compare a checksum you already have
Compare answers one question: do the current bytes have this hexadecimal digest? It does not look up a checksum, and it does not read a checksum file. Paste the hex into the field. The placeholder is “Paste expected hex digest”, and the line above the field says letter case does not matter. Ends are trimmed. The length then chooses the algorithm, because these four lengths do not overlap.
- 32 hex characters
- Compared as MD5. A match reads “MD5 matches this input.”
- 40 hex characters
- Compared as SHA-1.
- 64 hex characters
- Compared as SHA-256. There is no algorithm menu. A 64-character hex string is never treated as another algorithm.
- 128 hex characters
- Compared as SHA-512.
Anything else is an error, not a mismatch. A space or colon in the middle, a dash, a 0x prefix, a file name, or a Base64 string produces “Enter a 32, 40, 64 or 128-character hex digest.” The field is marked invalid. An empty field reads “Waiting for a checksum”. A digest pasted before any text or file reads “Enter text or choose a file to compare.”
A real disagreement, with the length and the alphabet still valid, reads “SHA-256 does not match this input.”, using whichever algorithm the length selected. Change one hex digit and keep every character inside 0–9 and a–f, and you get that mismatch. Change a digit to g and you do not. g is not hexadecimal, so the page reports the format error instead. That split matters when you are hunting a typo.
Before you check a download, try the abc SHA-256 above. Type those three letters with no line break, confirm the row, then paste the same digest in capitals into Compare. The status should be “SHA-256 matches this input.” Switching the rows to UPPER HEX or Base64 does not change that result. Compare always uses the lowercase hex of the raw digest, not the text currently drawn in the rows.
Published checksums usually arrive with extra characters. shasum -a 256 and sha256sum print the hex, then spaces, then the file name. Paste the hex only. certutil -hashfile puts a space between each pair of hex characters and wraps the digest in a heading. Delete the spaces, and do not paste the heading. For SHA-256 the command is certutil -hashfile your-file SHA256. PowerShell’s Get-FileHash prints a table. The Hash column is contiguous hex, upper case is fine, and the default algorithm is SHA-256. A trailing line break on the paste is harmless, because the ends are trimmed. A space that survived in the middle is not.
A match means the bytes you hashed have the digest you pasted, under the algorithm that length implies. It does not establish who published the file, and it does not mean the file is safe to open. Read the expected value from a source you trust, over a channel you trust, such as the project’s own HTTPS page. A checksum that travels in the same unofficial post as the download can match a substituted file exactly. This page cannot fetch that page or decide that you trust it. The check is about bytes.
Two files take two turns. The page holds one source. Hash the first file, copy the SHA-256, select the second file, and paste that digest into Compare. When the second file finishes, Compare runs again against whatever hex is still in the field. There is no second column of results.
MD5 and SHA-1, or SHA-256 and SHA-512
These are ordinary hashes. The same bytes always produce the same digest. There is no key, no salt, and no random value. That stability is why a checksum works, and why this page is the wrong place to hide something.
Choose SHA-256 when the checksum is yours to pick: a release you publish, a file you ask someone else to confirm, a value a test should expect. Choose SHA-512 when the written checksum is already SHA-512, or when you want the longer digest. You do not hash twice. Both rows fill together. Choose MD5 or SHA-1 when that is the string the other party already published. Older installers, firmware packages, and mirror lists often print one of those and nothing else. Hashing the file with SHA-256 will not agree with a published MD5, and the disagreement does not mean the download changed. Match the algorithm they printed. The Legacy label warns you off those rows for a new checksum. It does not stop you checking an old one.
A damaged copy and a crafted collision are different problems. A truncated download, a bad copy, or a single flipped bit changes an MD5 or a SHA-1 in practice, so a published MD5 still answers “does my copy match the bytes they hashed?” A collision is a stronger claim. Someone who can choose two different files can, for MD5 and for SHA-1, make those files share one digest. If the same untrusted party supplies both the file and the checksum, MD5 or SHA-1 does not tie the file to an honest publisher. Use SHA-256 for a check you are publishing now. Even then, the digest only ties the file to that checksum. It says something about a publisher only when you received the checksum from them on a channel an attacker cannot rewrite.
Hashing is not encryption. Encryption is meant to be reversed with the right key. A digest is a one-way fingerprint. Do not put text here in order to keep it secret, and do not send someone a digest and expect them to recover the text. Short secrets are also guessable. Anyone can try likely strings and see whether the digest matches. Nothing on this page slows that guessing down.
This is the wrong tool for storing a password. It does not compute HMAC. It does not compute a password hash such as Argon2, bcrypt, scrypt, or PBKDF2. There is no salt and no work factor. An MD5 or a SHA-256 of a password is not a password-storage scheme. Keep passwords in a password manager. When you need a new random password, use the password generator. Hashing that password here does not make it stronger, and the digest is not a stand-in for the password.
The 32 MiB line, and what stays on this device
The file limit is 32 MiB: 32 × 1024 × 1024 bytes, or 33,554,432 bytes. A file of exactly that size is accepted. One byte over is refused before it is read. The name and size still appear, the digests clear, the status reads “File is too large”, and the error reads “This file is over 32 MiB. Use a local checksum command for larger files.” Sizes use binary units. Under 1024 bytes the line shows B. From there to just under 1 MiB it shows KiB with one decimal, then MiB with one decimal. A file at the limit is shown as 32.0 MiB. A download page that says “32 MB” in decimal millions of bytes may still be under this cap. The error string means the binary MiB limit, not a round decimal 32.
The cap is there because the page reads the whole file into memory and passes that buffer to Web Crypto and to spark-md5. There is no percent-complete readout and no streaming mode. A file under the cap can still fail on a phone or in a busy browser. A failed read says “Could not read this file. Select it again or try another file.” The status is “File read failed”. A failed hash uses “Could not calculate the hashes in this browser. Try a smaller file or another browser.” The 32 MiB rule is only on the file picker. The text field has no character counter and no matching cutoff. A huge paste can still fail, and that failure uses the same hashing message, which talks about a smaller file even when the source was text.
For a larger file, hash it locally. shasum -a 256, sha256sum, certutil -hashfile, and Get-FileHash read from disk and can handle sizes this page will not. Bring the hex back only if you still want to compare it with a short piece of text. The big file itself should stay on disk.
The text and the file are not uploaded as a tool request. Choosing a file gives the browser a local handle, and the bytes are read in the page. The form says “Nothing uploaded”. That line does not describe every record a web server keeps for the page view. Access logs, and any optional page analytics, are in the privacy policy. Those logs do not include the text you typed or the contents of the file you selected.
A digest is not itself a secret. The text you typed still sits in the field until you edit it, switch to a file, or leave. On a shared or borrowed machine, do not paste a password, a private key, or a private document into the box just to hash it. The page keeps no history of earlier files or earlier digests. Reload or close the tab and they are gone. Copy the digest first if you still need it. Web Crypto’s digest function is available in a secure context, including HTTPS. This site is served over HTTPS. A browser without crypto.subtle cannot produce the four digests, and there is no server-side hasher that takes over.