How to generate a SHA-1 hash on Mac
Forty characters of hexadecimal, usually because something built a decade ago is asking for them. Rocket Hash produces a SHA-1 for a string or a file in a couple of seconds — and this page covers the harder part too: telling a file’s SHA-1 apart from the two other values on a Mac that look exactly like one, and knowing which half of SHA-1’s reputation applies to what you are doing.
A vendor’s download page from 2014 lists a SHA-1 and nothing else. An old integration or a build script asks for one by name. Or something you ran handed back 40 characters when you were expecting 64, because a surprising number of older tools still compute SHA-1 unless they are told otherwise.
Producing the digest is the easy part and it is a few paragraphs down. The part worth your attention is everything after: forty hexadecimal characters on a Mac are one of three quite different things, and telling them apart saves an afternoon. Then there is the question of weight. SHA-1 did not fail all at once — it lost one security property in 2017 and kept the other, and which of the two you are leaning on is the entire question.
If the thing you need a SHA-1 of is a string, the SHA-1 generator on this site computes it in the browser as you type and uploads nothing. A file is a different job and no web page does it: the Files and Verify tools are what the steps below use, and neither of them asks you to compare 40 characters by eye.
If something is asking you to match a SHA-1 that already exists, produce it and move on — that is a legitimate use and the rest of this page is background. If you are choosing an algorithm for something new, do not choose this one; SHA-256 costs you nothing extra and is not on anybody’s retirement list.
What a SHA-1 digest is
SHA-1 takes an input of any size and returns exactly 160 bits — 20 bytes, written as 40 hexadecimal characters. A one-letter string and a 50 GB disk image both come back as forty characters, because the length of the output has nothing to do with the length of the input.
Two values are worth recognizing on sight, because between them they are the fastest test of whether a tool is doing real SHA-1. The digest of an empty input is da39a3ee5e6b4b0d3255bfef95601890afd80709, and of the three letters abc it is a9993e364706816aba3e25717850c26c9cd0d89d. The second is one of NIST’s own published test vectors. Anything that disagrees with those is not computing SHA-1, whatever the label says — testing a hashing tool in thirty seconds uses the same trick for the other algorithms.
Change a single bit of the input and roughly half the 160 output bits flip, which leaves two or three of the 40 characters standing by luck and rewrites the rest. Two digests either match exactly or tell you nothing at all about how similar the inputs were; there is no such thing as a near miss.
Generate a SHA-1 hash on your Mac
-
Open the Text tool
Click Text in the sidebar — the cyan icon marked Aa, above Files and Verify. Type or paste your string into the field. Every digest recomputes as you type, so there is no button to press and nothing to save first, and this part of the app is free.
-
Read the SHA-1 row
The rows are grouped, and SHA-1 is not filed with the SHA-2 family where you might go looking for it. It sits under LEGACY, beside MD5. That grouping is a judgment rather than a filing accident, and it is the same judgment NIST, the browser vendors and the certificate authorities all reached years ago.
-
Copy the full forty characters
Click the row and the digest goes to the clipboard. Do not transcribe it off the screen instead: long digests are shortened in the middle with an ellipsis so the rows stay readable, so what you can see is not the whole value. Copying digests out of the window covers the labeled-block route for when you need more than one.
-
Do the same for a file
Drag the file into the Files tool instead, or add it with the + button. Pick the algorithm with the # control in the toolbar, or open the row’s disclosure chevron to see every algorithm for that file at once. The file is read exactly once either way, so asking for SHA-1 alongside SHA-256 does not cost a second pass over the disk.
What 40 hex characters might actually be
This is where the time goes. Three different values you will meet on a Mac are forty lowercase hexadecimal characters, they are not interchangeable, and nothing about their appearance tells you which one you are holding.
| Forty characters of | What it actually covers | Where it turns up |
|---|---|---|
| A file’s SHA-1 | Every byte of the file and nothing else | Download pages, release notes, checksum manifests |
| A Git object id | A short header plus the content | git log, commit URLs, git hash-object |
| A RIPEMD-160 digest | The same bytes, a different function | Bitcoin addresses, some older packaging |
The Git one catches nearly everybody. A Git blob id is not the SHA-1 of the file: Git hashes the word blob, a space, the content length in bytes and a zero byte, and only then the content. For a three-byte file containing abc, that is the difference between a9993e36… and f2ba8f84… — two numbers that were never going to match, for a reason that has nothing to do with corruption.
Nothing about the characters themselves will tell you which of the three you are holding, so the defense is knowing where the value came from. Forty characters in a commit URL, a git log line or a pull request title is an object id. Forty characters on a download page, next to a filename and a size, is the file’s own SHA-1. Forty characters in a Bitcoin context are probably neither. Why two tools give different hashes for the same file works through the rest of the reasons a digest disagrees with itself, and identifying a checksum from its length covers the other ambiguous lengths.
Matching a SHA-1 somebody already published
Producing the digest is only half the job if the point was to compare it against a value on somebody else’s page. Reading 40 characters twice is exactly the task eyes are worst at — attention confirms what it expects somewhere around character six and coasts to the end — so give both halves to Verify instead. Choose Against a Checksum, drop the file in, paste the 40 characters, and the answer arrives as a sentence under a green seal rather than as two strings to line up by hand.
You do not have to declare that the value is a SHA-1. The algorithm is worked out from the checksum itself, and of the eight the app computes only SHA-1 is 40 characters long, so the length decides it. What the length cannot decide is the question from the table above: paste a Git object id and you have pasted 40 characters of something else, which will never agree with the file no matter how many times you re-download it. Rule that out before you conclude anything.
When nobody published a value at all and you simply want to know whether two copies are the same — a file before and after a transfer, a restored backup beside the original — the other mode fits better. File vs. File puts two drop wells side by side with a swap control between them and settles it byte for byte with SHA-256, so there is no reason to drag SHA-1 into a comparison you are making for your own benefit. Comparing two files directly covers that mode on its own.
How far you can trust a SHA-1
Two separate promises hide inside the phrase “secure hash”, and SHA-1 has broken exactly one of them. Keeping them apart is the difference between a sensible decision and a superstition.
- Collision resistance — gone. In February 2017 researchers at Google and CWI Amsterdam published two different PDF files with the same SHA-1 digest. A 2020 result made it worse in the way that matters, producing a collision where the attacker chooses a prefix of both files in advance, for roughly $45,000 of rented GPU time. You do not need to be a government to buy that.
- Preimage resistance — intact. There is still no practical way to take a SHA-1 digest and produce a file that matches it. Nobody can look at a value you recorded last year and manufacture something that hashes to it.
The decision rule falls straight out of that gap. A collision attack means crafting both files together, in advance, which tells you when it can and cannot reach you. If the file existed before anyone had a motive — a release you built, an archive you made, a master copy you are re-checking six months later — then a SHA-1 you wrote down still pins those bytes, and a mismatch still means something changed. If the file arrived from somebody you have no reason to trust, a matching SHA-1 tells you only that you hold one of the files they prepared, and it cannot tell you which one.
This is also why SHA-1 is still entirely good at the dull job: catching a truncated download, a failing cable or a disk going soft. Accidental corruption has no agenda and cannot construct anything. What SHAttered actually broke works through the attacks properly, including why the answer was never “run it twice”.
NIST barred SHA-1 from new digital signatures more than a decade ago, and has said it will withdraw the algorithm entirely by the end of 2030. If something you own still depends on it, that is a deadline rather than a hint.
Where SHA-1 is still everywhere
For a function this publicly broken it is remarkably hard to avoid, and that is usually a sign the use in question never depended on the property that broke.
- Git. Every commit, tree and blob is addressed by a SHA-1. Git has shipped a hardened variant since 2017 that detects the known collision construction and refuses it, and the project is migrating its object format to SHA-256.
- HMAC-SHA1. Still considered sound, and not by luck: HMAC’s security does not rest on the collision resistance of the hash inside it, which is precisely why breaking SHA-1 did not break HMAC-SHA1.
- BitTorrent. Version 1 of the protocol identifies pieces by SHA-1; version 2 uses SHA-256. Both are in circulation.
- Old release pages and internal scripts. Firmware archives, vendor download tables and automation written in 2012 and never revisited since.
Troubleshooting
I wanted SHA-256 and got 40 characters
Whatever produced that value was computing SHA-1, and it probably did not say so — defaulting to SHA-1 quietly is a habit of tools written before 2010. Read the length before you read any label: 40 characters is SHA-1 and 64 is SHA-256. The app states it instead of assuming it, with a colored algorithm chip at the start of every row and the SHA-2 group listed above the LEGACY one.
My digest does not match the Git hash for the same file
It is not supposed to. Git’s object id covers a header — the object type, the content length and a null byte — in front of the content, so the two numbers describe different byte strings. A Git object id only ever matches another Git object id; the SHA-1 row in the app is the digest of the file’s bytes and nothing else.
The value is only seven characters long
Then it is an abbreviated Git id rather than a checksum. Git lets you name an object by any unambiguous prefix of its id and seven characters is the customary short form. You cannot reconstruct the missing thirty-three from it, and it can only be expanded inside the repository it came from, which is the only place that knows the rest.
The publisher only offers a SHA-1
Check it anyway. It will catch every one of the things that actually goes wrong with a download — a truncated transfer, a proxy that mangled something, the wrong build for the wrong architecture. What it cannot do is prove the publisher is who they claim to be, but a SHA-256 published on the same page cannot do that either.
It is 40 characters but nothing matches
Rule out a Git object id first, then a value that wrapped across two lines in an email and picked up a space in the middle. Then check the case: hexadecimal is not case-sensitive as a number, but a script doing a literal string comparison has no idea about that, so normalize both sides to lowercase before you compare them.
Frequently asked questions
How many characters is a SHA-1 hash?
40 hexadecimal characters — 160 bits, or 20 bytes, which are three ways of saying the same thing. The length never varies with the input. Be careful with that number, though: a Git object id and a RIPEMD-160 digest are also 40 hex characters, so length alone does not identify a value as a file’s SHA-1.
Is SHA-1 still safe to use in 2026?
It depends which property you need. Collisions — two different files with the same digest — have been public since 2017 and purchasable for about $45,000 since 2020, so SHA-1 is finished for signatures, certificates and anything where an adversary supplies the content. Nobody can reverse a digest or forge a match for a file that already exists, so SHA-1 still detects accidental corruption perfectly well. NIST plans to withdraw it entirely by the end of 2030.
Can a SHA-1 hash be decrypted or reversed?
No. SHA-1 is not encryption — it discards information, so there is nothing to decrypt and no key that would help. There is also no practical preimage attack, meaning no method of working backwards from a digest to an input that beats guessing. Sites offering “SHA-1 decryption” are searching a table of previously hashed common passwords, which works for 123456 and for nothing else.
Can I get a file’s SHA-1 and SHA-256 in one go?
Yes, and it costs one pass over the disk rather than two, because the file is read a single time however many digests you ask for. In the Files tool, open the disclosure chevron on the file’s row and every algorithm appears for that one file — SHA-1 under LEGACY, SHA-256 under SHA-2. That is the practical way to retire a SHA-1: publish both values for a while, then drop the old one once nothing is still asking for it.
Is SHA-1 better than MD5?
Marginally, and not in a way you should build on. Both have lost collision resistance; the difference is price. MD5 collisions have been constructible since 2004 and now take seconds on a laptop, while a SHA-1 collision still needs rented GPU time costing thousands of dollars. For detecting accidental damage either is fine; for anything an attacker can influence, neither is — see whether MD5 is still safe.
Why does Git still use SHA-1 if it is broken?
Because Git uses the digest as an address, not as a signature, and because changing it means rewriting every identifier in every repository in the world. Git has also shipped a hardened SHA-1 since 2017 that spots the known collision construction and rejects it, and the object format is being migrated to SHA-256. In the meantime a repository’s integrity rests on signed tags and commits rather than on SHA-1 alone.