How to hash files completely offline on Mac
The file is a client's unreleased build, an HR export, or a disk image from an incident, and its SHA-256 is owed to somebody who will never see the file itself. A web form is not an option you have. Here is how to produce the digest in Rocket Hash with the network switched off, and how to show somebody else that nothing left the machine.
There is a category of file where probably fine is not a standard you are allowed to apply. Material covered by an NDA. A copy of a production database. Evidence you may have to account for later. An unreleased binary. For those, the interesting question is not whether a particular tool uploads anything — it is whether you can say, and demonstrate, that nothing could have.
The whole job is local, and it always was. Computing a digest needs the file and some arithmetic; there is nothing a network could contribute. The Text, Files and Verify tools all sit inside a sandboxed app with no network code in it anywhere — nothing to sign in to, nothing to activate, no telemetry — so not one of them behaves differently with the Wi-Fi off. Do the work with the network down anyway, and the claim stops resting on anybody's description of the software, including the publisher's.
This page is the procedure, in the order that makes it provable: disconnect, check the material is not sitting somewhere that will sync, compute, and confirm. If what you actually want is to audit one particular web page rather than remove the network, how to tell whether a hashing page uploads your file is that test instead. It is not a question you have to settle here: the free calculators on this site hash text you type and nothing else, so a file like this one never had a web route in the first place.
Disconnect first, then hash. That turns “I believe this tool is local” into “nothing on this machine had anywhere to send it”, which is a claim somebody else can check without trusting your judgment.
Why offline is a stronger claim than “nothing is uploaded”
Three statements about the same run look similar and are not equally strong.
- The tool says it does not upload anything. A claim by the party with an interest in it.
- I watched it, and it did not upload anything. True of one run, of one version, on one day.
- The machine had no route to send anything. True of everything running on it, including the parts you did not think to watch.
Only the third survives a question from a client, an auditor or a colleague, because it does not depend on what you believe about any particular piece of software. It is also the cheapest of the three to produce: one click in the menu bar, and you are done deciding whom to trust.
Produce the digest with the network off
-
Disconnect the Mac
Turn Wi-Fi off from the menu bar rather than just leaving the network you are on, and unplug Ethernet or the dock carrying it. Watch for the two that come back on their own: a personal hotspot your Mac knows how to join, and a Thunderbolt or USB adaptor that quietly keeps a link up. The menu bar icon is the thing to check, not the Wi-Fi network list.
-
Get the material out of any synced folder
This is the step people skip, and it is the one that undoes the rest. If the file lives in iCloud Drive, Dropbox, Box, Google Drive or OneDrive, hashing it offline protects nothing — the file is already replicated, or will be the moment you reconnect. Copy or move it to a plain local folder outside all of them first. While you still have a connection, make sure it is actually on the disk rather than a placeholder, because an evicted cloud file cannot be read at all once you are offline.
-
Compute the digest
Drag the file or the folder into the Files tool and read the digest off the row; the Algorithm control in the toolbar picks which one, and the disclosure chevron on a row opens every algorithm for that file out of the same single read. For a whole tree, the export button writes a manifest you can check the same folder against later. The status bar summarizes what you handed over on the left and what has finished on the right, and none of it changes with the network down, which is the point.
-
Confirm the answer appeared anyway
It did, and that is your evidence. A tool that needed a server would have failed here, visibly and immediately. If you want more than an absence, Activity Monitor's Network tab lists bytes sent per process, and with every interface down there is nothing for it to show — which is a weaker check than the first one, because it confirms what you already arranged.
A run over a whole tree is worth exporting before you reconnect. The export button in the toolbar writes a plain text file with one line per file — the digest first, two spaces, then the path — and that file, rather than a screenshot of the window, is the record you can hold the same folder against in six months. Two lines of one look like this:
70d5744419c8ddc6d3dae89605bf59a2a66600957eba92d1e24e2ca16641788a disk-image.dmg
2eb0ed5ec63fee9ef07693f1def75fc42f39850fd3d76d934f346a44d3f1218f interviews/transcript-04.docxThat is the two-column format every checksum file has used for thirty years, which is most of why it is worth keeping: it stays readable on a machine with none of your software on it. How to read a SHA256SUMS file goes through it line by line, and checking a folder against a manifest covers the re-check a month later. For one value rather than a list, the Verify tool takes the digest you were given in Against a Checksum mode and works out which algorithm it is from the string itself.
What you can safely send afterwards
The digest is not the file, which is why a client who could never email you the material can ask you for its checksum. Sixty-four hexadecimal characters say as much about a 40 GB archive as about a one-line note, and there is no practical way to work backwards from them to either.
Two things about it do leak, and both are easy to overlook.
- A digest confirms a guess. It is worth nothing against a unique 8 GB disk image, and quite a lot against a document drawn from a handful of predictable possibilities — whether a digest itself is sensitive works through where that line falls.
- A manifest is a directory listing. An exported manifest pairs every digest with its filename and path, and on confidential material the filenames are frequently the sensitive part.
2026-q3-redundancies-final.xlsxdiscloses more than its digest ever could. Read an export before you send it, and trim it if it names things it should not.
Sending a checksum to somebody covers getting it there without it being mangled. One thing a checksum cannot do is defend itself: send the digest by the same route as the file and anybody able to alter one can alter the other. Against corruption that pairing is fine; against somebody deliberately substituting the file it proves nothing, so the value has to reach the recipient some other way — read out on a call, or from a place they went to themselves.
Reading a file from a server means the file's bytes cross the network to reach your Mac, whatever the hashing tool does. If the constraint is that the material must not traverse the wire, get it onto local storage by an approved route first.
What the app can still do with no connection
Nothing in it degrades when you disconnect, because nothing in it was ever talking to anything. What that leaves you with is worth listing, because on confidential material the hard part is rarely the arithmetic — it is volume, and having something at the end that a second party can re-check.
- Strings that never become files. The Text tool shows all eight digests as you type, with the byte count under the field and a Copy All button beside it, and clicking any row copies that one digest. A passphrase, a key or a single clause you need the digest of never has to be written to disk at all. It is also the free tool, so a locked-down Mac can do this much whatever else is unlocked on it — hashing text covers what counts as a byte.
- A hundred thousand files in one queue. Drop a whole tree into Files and each file is read exactly once however many digests come out of it, with memory flat at roughly 16 MB whether the file is 2 MB or 400 GB. Live throughput and an estimate of the time remaining sit on the right of the status bar, which is what lets you decide whether to wait.
- A run you can interrupt. A long job pauses mid-file and resumes from the exact byte rather than starting the file over, which turns an all-afternoon evidence disk into something you can work around rather than sit next to.
- A verdict instead of 64 characters. Verify takes either a checksum somebody gave you or a second copy of the file. In File vs. File two drop wells sit side by side with a swap control between them, and the answer arrives as a green seal and a sentence — “Files are identical.”, with the algorithm underneath.
The honest limit runs the other way. On a disconnected Mac nothing can fetch a publisher's value for you, so whatever you are comparing against has to arrive by the route you arranged: typed in, read off a printout, or carried in on the same stick as the file. The app compares; it does not go looking.
Air-gapped and managed Macs
On a locked-down fleet the relevant property is not that an app behaves well on the network — it is that it has no network code to behave with. There is no endpoint to allow-list, no domain to whitelist, no telemetry to negotiate with a security team, and no account to provision. For a Mac that lives in a room without a cable, the only moment a connection is needed is the install from the Mac App Store; after that, nothing.
What a security team asks next is usually not whether the app stays quiet but whether its arithmetic is right, and that is the one claim on this page you do not have to take from anybody. Every algorithm in it is checked against the test vectors NIST publishes, and you can repeat one of those yourself in the Text tool in about thirty seconds: type abc and the SHA-256 row must read ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. Anything that disagrees is broken, and checking that a hashing tool is telling the truth has the rest of the vectors to try.
Rocket Hash carries no account and nothing to renew, which matters on a fleet for a dull reason: there is no sign-in left to fail six months after somebody provisioned the machine.
Troubleshooting
The file will not open now that I am offline
It is a cloud placeholder rather than a file. With storage optimization on, macOS evicts the contents of files you have not used and leaves a stub that points at the copy in the cloud, so reading it requires downloading it. Reconnect, make sure the file is genuinely downloaded, then disconnect again — or better, keep this kind of material out of synced folders entirely.
Wi-Fi turned itself back on
It happens after a restart, after some updates, and whenever a known hotspot is in range. On a long run over hundreds of gigabytes, glance at the menu bar again when it finishes rather than assuming the state you set an hour ago has held.
I need to prove to somebody else that nothing was sent
Give them a procedure rather than a screenshot. Ask them to disconnect, hash the same file, and compare with your value — a digest that reproduces on a disconnected machine they control is worth more than any assurance you could write. If they want the arithmetic established rather than assumed as well, type a NIST test vector into the Text tool in front of them and let them check the row against the published value.
The folder will not go in at all
That is macOS rather than the network. Desktop, Documents, Downloads and every mounted volume sit behind a consent granted per app and per location, and a sandboxed app reads only what you hand it — which is the same property that makes it safe to point at this material in the first place. Drag the enclosing folder in from a Finder window, because the drag is itself the grant and it carries the whole tree, or turn the matching switch on in System Settings ▸ Privacy & Security ▸ Files and Folders. Permission denied when hashing a folder works through the four separate gates.
Does hashing put the original at risk?
No. Hashing is a read from start to finish: nothing is written, no modification date changes, nothing moves. That is what makes it safe to point at a master copy, an archive or an evidence disk you are not allowed to alter — see whether hashing changes a file for the longer answer. The one real hazard is hashing something that is still being written, which gives you a digest nobody can reproduce.
Frequently asked questions
Can I hash a file without an internet connection?
Yes — hashing has never needed one. The calculation uses only the file's bytes and your CPU, so an app with no network code in it produces exactly the same digest with every interface switched off as it does online. There is no sign-in, no activation and no lookup involved, which is why nothing in the window behaves any differently once you disconnect. The only connection involved anywhere is the one that installs the app from the Mac App Store.
Is it safe to hash confidential or NDA-covered files?
Locally, yes, and hashing is unusually safe because it only reads — nothing is written and the original is untouched. The risk lies entirely in where you do it. Keep the file off web forms, out of synced folders, and off network shares, and the digest becomes a fact you computed rather than a question you asked somebody else.
How do I prove that a file was hashed offline?
Make it reproducible instead of documenting it. Ask the other party to disconnect their own Mac, hash the same file, and compare digests — a value that reproduces on a machine they control is stronger evidence than any log or screenshot. If they want the arithmetic itself established rather than assumed, a NIST test vector typed into the Text tool settles that in thirty seconds.
Is it safe to email the checksum of a confidential file?
Usually yes — the digest is 64 hexadecimal characters and the file is not in them. The thing to read before you send is a manifest, because it pairs every digest with a filename and a path, and on confidential work the names disclose more than the digests do. If the recipient needs the value to prove the file was not substituted, send it by a different route from the file itself.
Does hashing a file in iCloud Drive upload it?
No. Hashing reads; it never sends. The complication runs the other way — if macOS has evicted the file's contents to save space, reading it has to download it first, so you need a connection before you can hash it at all. Move confidential material out of synced folders and neither question arises.
Can I verify a file against a published checksum while I am offline?
Yes. Both halves of the comparison are already on the Mac — the checksum you paste into the Verify tool in Against a Checksum mode, and the digest it computes from the file you drop in — and the algorithm is read from the string you pasted, so there is nothing to look up and nothing to set. What a disconnected Mac cannot do is fetch the publisher's value for you. Bring it in before you pull the network: written down, read off a printout, or carried in alongside the file.
Which algorithm should I use for confidential material?
SHA-256, for the same reason as everywhere else: 64 hexadecimal characters, no known collisions, and universally supported. Avoid MD5 and SHA-1 for anything you may later need to stand behind — both have lost collision resistance, MD5 since 2004 and SHA-1 publicly since the 2017 SHAttered demonstration.