Is it safe to hash files on a website?

You searched for a SHA-256 generator, the first result has a drop zone in the middle of it, and the file you want to check is a client's database export. The page says nothing about where the file goes. The reasonable question — is this thing uploading my file? — has no answer you can get by looking at it.

The short version: it depends entirely on which page you landed on, and the two kinds are indistinguishable from the result. A page that hashes locally reads your file in chunks with JavaScript and never makes a request. A page that hashes server-side posts the whole file, computes the digest on a machine you know nothing about, and sends back 64 hexadecimal characters that look exactly the same. You can find out which you have in about a minute, and the rest of this page is how.

What follows is the test, what an upload costs beyond the obvious, whether the digest itself gives anything away, and the cases where an online tool is genuinely the right tool. If the underlying question is what a checksum is worth in the first place, what a checksum actually proves is the page for that. If you already know the answer is no and you want the procedure, skip to hashing with the network switched off.

Why you cannot tell by looking

Hashing in the browser has been practical for years. The crypto built into every current browser hashes a whole buffer in one call, which covers text and small files; for a large one a page uses a JavaScript implementation, reads the file in pieces, and keeps only the algorithm's small internal state between them. That is how a page can hash a disk image of any size without filling your memory. Neither route needs a server.

Server-side hashing is just as easy to build and considerably easier to monetize, because a server that has your file can count requests, show ads against a progress bar, and keep a history. So both exist, in roughly equal numbers, wearing the same interface.

Some signs are suggestive. A stated file size limit — 10 MB, 50 MB, 100 MB — usually means an upload, though it is not proof: a page that hands the whole file to the browser's one-call digest has to fit the file in memory, so a cap can also mark a local tool that was written the lazy way. An upload progress bar, a queue position, a shareable results link, a sign-in, or eight seconds of waiting on a 2 MB file are firmer tells. Signs pointing the other way are weaker: a digest that arrives faster than an upload could have finished — a few seconds on a 4 GB file, against the twenty minutes a 25 Mbit/s connection would need — is good evidence of local work, and the words nothing is uploaded in the page copy are evidence of nothing at all. Marketing claims are not a security control.

Test any page in under a minute

Your browser already ships the instrument. This works on any hashing page, and it costs less time than reading the privacy policy.

1. Open the network inspector first

   In Safari, enable the developer features in Settings under Advanced, then open Web Inspector and select the Network tab. In Chrome, Edge or Firefox, open the developer tools and do the same. Do this before you load the page, or reload it afterwards, so the inspector sees the whole conversation rather than the tail of it.

2. Use a decoy file, not the real one

   Make a junk file — a screenshot, a few lines of nonsense in TextEdit, anything whose escape would not cost you anything. Make it large enough to be unmistakable in a list of requests, a megabyte or two. If the page turns out to upload, the test itself has already leaked whatever you fed it, which is an excellent reason not to feed it the thing you were worried about.

3. Look for a request the size of your file

   Drop the decoy into the page you are testing and watch the request list. A local page does nothing: the digest appears and the Network tab stays exactly as it was. A server-side page produces one request carrying roughly your file's size — the size column is the tell, and it is hard to misread a 2 MB request. Small requests for fonts, icons and analytics are normal on almost every page and are not what you are looking for.

4. Then switch the network off and try again

   With the page already loaded, turn Wi-Fi off and hash the decoy once more. If a digest still appears, the arithmetic happened on your machine, because there was nowhere else for it to happen. Of the two checks this is the stronger, and the only one that needs no interpretation. The honest caveat: in principle a page could hold the bytes and send them when you reconnect, so pair this with the empty Network tab rather than treating it as proof on its own.

What an uploaded file actually costs

The obvious cost is that a stranger now has your file. The less obvious costs are the ones that matter more.

• It does not leave when you close the tab. A file that reached a server reached its logs, its temporary storage, its nightly backups and quite possibly a content delivery network in between. A delete button, where one exists, applies to the copy you can see.
• You may not have had the right to send it. Client material under an NDA, personal data belonging to other people, unreleased code, anything covered by a contract you signed — whether uploading it was safe is a smaller question than whether it was permitted.
• The filename travels with the file. acme-merger-draft-7.docx tells a reader most of what they wanted to know before anyone opens it.
• It defeats the point of the exercise. This is the one people miss. The entire value of a checksum is that it is an independent check: you compute the digest yourself, from the bytes you actually hold. Send the file to a server and you are trusting that server to hash what you sent, to hash it correctly, and to report the result honestly. You have not verified your download — you have asked a stranger whether your download is fine.

Plenty of tasks are fine to hand to a web service. Verification is the odd one out, because its whole purpose is to remove your dependence on somebody else's word.

Is the digest itself sensitive?

Usually not, and it is worth being precise about why, because the internet is full of pages offering to decrypt hashes.

A digest cannot be turned back into its input. SHA-256 discards information — any amount of data in, exactly 32 bytes out — so there is nothing to reverse, and no known method of producing an input that matches a given SHA-256 digest beats trying candidates one at a time. That property is called preimage resistance, and it is not the property MD5 and SHA-1 lost. What those two lost is collision resistance: the ability to stop somebody constructing two different inputs that share a digest. MD5 collisions have been trivial to produce since 2004, and SHA-1 collisions were demonstrated publicly in 2017 with the SHAttered work. Neither break lets anyone recover a file from its hash. The distinction matters in both directions — a broken algorithm is not a leaky one, and a leak-proof algorithm is not necessarily safe to verify with.

There are two real caveats. A digest is a confirmation oracle: anybody holding a candidate file can hash it and see whether it matches. For a unique 4 GB video that is worth nothing to an attacker. For a file drawn from a small set of possibilities — a standard contract with one name changed, a payroll export in a known format, a short message — a digest can confirm a guess, and that is disclosure by any sensible definition. The second caveat is that the sites advertising hash decryption are doing exactly this: looking your digest up in a table of previously hashed common inputs. It works for password123 and it works for nothing with real entropy in it.

When an online tool is the right answer

Plenty of the time, and it would be dishonest to pretend otherwise. The question is not whether web tools are bad; it is whether this particular input has anything to protect.

Where nothing in the transaction is secret, the privacy question evaporates. A string that is not a confidential string — a config value, a version number, a digest somebody quoted at you, a line you want to set against a published value — gives a server nothing it could sell, log or lose. If you are sitting at a borrowed Mac with nothing installed on it, a web page is exactly the right shape of tool for that.

The calculators on this site are the local kind, and they are text only. Type or paste into the SHA-256 generator, or into its MD5 counterpart, and the digest updates as you type, with the byte count underneath it. The Check a checksum tab takes a value somebody published and compares it against the digest of that text. There is no upload endpoint in the page and no file input either — none of them will read anything off your disk. Run the test above on them anyway: the whole argument of this page is that you do not take this on faith from anybody, including us.

Which leaves the case you probably arrived with. A file — the ISO, the client export, the 40 GB disk image — is not something any page here will hash for you, at any size. Reading a file off your own disk is work for software that is already on the machine, which is the next section.

What a local app removes

It removes the need to ask. Rocket Hash has no network access of any kind: no telemetry, no accounts, no cloud, nothing to audit per visit because there is no request that could be made. It is sandboxed and uses the hardened runtime, it is written in Swift against Apple's own frameworks with no third-party code in it, and hashing text is free. On a locked-down Mac there is nothing to allow-list in an egress firewall, because there is nothing to allow.

That is a different kind of assurance from a clean Network tab. A clean Network tab tells you what one page did on one visit. An app with no networking code cannot develop an upload feature between your morning and your afternoon. The file itself goes into Files, which reads it once off your own disk however many digests you asked for; when what you hold is a published checksum rather than a second copy of the file, Verify takes the value you paste and works the algorithm out of the string itself. If you want to be sure the arithmetic is right as well as private, checking a hashing tool against known answers takes about thirty seconds, and hashing a file without Terminal covers the route in if you have never done this locally before.

Troubleshooting

The page says “no upload” — is that not enough?

It is a claim in the same document as the drop zone, written by whoever wrote the drop zone. It costs nothing to make and nothing to break. Treat it as a hypothesis and spend the minute to test it; a page making an honest claim will pass easily, which is rather the point of testing.

The network tab shows requests but they are tiny

Then they are almost certainly the page doing ordinary page things — fonts, a stylesheet, an icon, an analytics ping. What you are looking for is a single request whose size tracks your file's size, and which appears at the moment you add the file. Add a second decoy of a very different size and watch whether the request size follows.

It is a big company, surely it is fine

Brand recognition is not a retention policy, and a well-run service with an impeccable record still has your file. The relevant question is rarely whether they are malicious; it is what their logs keep, for how long, and whether you were allowed to send somebody else's data there at all.

I already uploaded something I should not have

Assume the copy persists, and act on that basis rather than on a delete confirmation. If the file contained credentials, API keys or tokens, rotate them now — that is the part you can actually fix. If it belonged to somebody else, tell whoever owns it, because a disclosure they find out about later is a much worse conversation than one you start. Then switch to a local route so it cannot happen twice.

Safari's inspector will not open

The developer features are off by default. Turn them on in Safari's settings under Advanced, and Web Inspector becomes available from the Develop menu. If you would rather not enable it at all, the network-off test from step four works on its own and needs no developer tools whatsoever.

Frequently asked questions

Do online hash generators upload your file?

Some do and some do not, and the interface rarely tells you. Browsers can hash a file locally in JavaScript without sending anything, but server-side tools are just as common and produce an identical-looking result. A stated file size limit usually means an upload, though a page that hashes the whole file in one call has to fit it in memory and may cap it for that reason instead. The only reliable check is to watch your browser's network inspector, or hash a decoy file with the network switched off.

Is it safe to hash a confidential file on a website?

Not unless you have tested that particular page, and even then the test only describes the code that page served you today. For material covered by an NDA, personal data belonging to other people, or anything unreleased, the sensible default is a local tool — the question of what a server keeps never arises if no server is involved.

Can someone recover my file from its SHA-256 hash?

No. SHA-256 throws information away, so there is nothing to reverse, and no practical method exists for producing an input that matches a given digest. The real caveat is different: a digest lets anybody who already has a candidate file confirm a match. For a unique large file that is harmless; for a file drawn from a small set of likely possibilities, a digest can confirm a guess.

How can I tell whether a hash tool runs in my browser?

Open the developer tools, select the Network tab, and hash a junk file: a local tool adds no request, while a server-side one produces one roughly the size of your file. Then disconnect from the network and hash again — if the digest still appears, the work happened on your machine.

Are the hash calculators on this site uploading anything?

No, and there is less to send than there used to be: they take text, not files. What you type is hashed in the tab as you type it, there is no file input on the page and no upload endpoint for anything to go to, and the Check a checksum tab compares a value you paste against the digest of that same text. Please verify that rather than believe it — the network inspector stays empty, and the page keeps working with the network switched off. Hashing a file is not something these pages do at all; that is what a local app, reading your disk directly, is for.

Is it safer if only the hash is sent to the server instead of the file?

Much safer, but not nothing. The digest cannot be turned back into the file, so the contents are not at risk. What does travel is the fact that you hashed something, usually the filename, and a value anybody holding a candidate file can test against — which for a short or highly predictable file is enough to confirm what it was.

Is it safe to hash a password on a website?

Never type a live password into a hash tool, local or not. Beyond the obvious risk of where it goes, a plain SHA-256 is the wrong function for password storage in the first place, because it is fast enough for a GPU to try billions of candidates a second. Password hashing wants a deliberately slow function such as bcrypt, scrypt or Argon2.