How to hash a file on Mac without using Terminal

Somebody has told you to check a download, and the instructions assume a command line. Worse, the instructions were usually written for Linux, so following them on a Mac can end in command not found — and now you are debugging somebody else's tooling instead of checking a file.

None of that is necessary. A digest is a property of the bytes, not of the program that reads them, so a window you drop a file into produces character-for-character the same 64 characters anything else would. This page is the drag-and-drop route end to end: where each thing those instructions asked for lives in the window, what the file row is telling you, and how to hand the comparison at the end to the app instead of doing it with your eyes.

The same arithmetic, either way

It is worth being clear about this before you trust a window over a command prompt, because the instinct that the terminal is somehow more authoritative is common and wrong. SHA-256 is a fixed, published specification with fixed, published answers; the three letters abc hash to ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad in a shell, in a browser, in an app, on Linux, and on a machine built in 2009.

There is no implementation latitude and no rounding. If two tools disagree about a file, one of them is defective or — far more likely — they were not given the same bytes. Checking that a hashing tool is telling the truth is thirty seconds of work and settles the question permanently, using values NIST publishes for exactly this purpose.

What changes between the two routes is not correctness but ergonomics. The command gives you a string and leaves the comparison to your eyes; a window can hold the file, the algorithm and the published value at once, and tell you whether they agree.

Drag, read, copy

1. Open the Files tool

   Click Files in the sidebar — the blue document icon, between Text and Verify. This is the tool that works on things stored on disk; the Text tool above it hashes what you type into it, which is a different job and a common first-time wrong turn.

2. Set the algorithm

   The Algorithm control in the toolbar, marked with a #, decides what gets computed as files arrive. Choose SHA-256 unless the value you are checking against is a different length — and if you are not sure which one you want, skip the decision entirely and expand the row afterwards to see every algorithm at once.

3. Drag the file in

   Drag it out of the Finder and drop it on the window, or use the add button in the toolbar to pick it from an open panel. Folders are accepted too, and everything underneath them is queued. Dragging is worth preferring for one non-obvious reason: it hands the app access to that specific file, which sidesteps the folder permission prompts macOS otherwise raises.

4. Read the row

   The file becomes a single row: its icon, its name in bold, the folder it came from underneath that, its size, and then the digest. Check the name and the folder before you read the digest — hashing installer (1).dmg when you meant installer.dmg produces a perfectly correct answer to the wrong question. The status bar along the bottom counts what has finished.

5. Copy the digest

   The copy button at the end of the row puts the digest on the clipboard. The disclosure chevron beside it expands the row to all eight algorithms for that file — eight digests out of the single read the file already got, where eight commands would have read it eight times. The export button in the toolbar writes the whole list out as a file rather than a clipboard's worth.

6. Compare it with the published value

   You can paste your digest and the published one onto consecutive lines and look at them, and for one file that is fine. Better is not to do the reading at all: the Verify tool takes the file and the pasted checksum, works out the algorithm from the length of what you pasted, and answers with a seal and a sentence instead of two strings — checking a file against a published checksum covers that route properly.

Where each thing lives in the window

Whatever the README told you to produce, it is one of about seven things, and each of them is a control you can see. Laid out side by side the list is unexciting, which is rather the point.

Two of those deserve a note. The Algorithm control decides what is computed as files arrive, but it is not a commitment: the chevron on a finished row expands it to all eight digests, and because the file was read once on the way in, that expansion costs no second pass over the disk. And the export button writes the same two-column format published checksum lists use — one line per file, digest first, then the filename — which is what makes an exported list readable by whoever you send it to, on whatever system they are using.

Let the window do the comparing

The reason the instructions felt like work is not the hashing. It is the last step: holding 64 characters in your head while your eye travels between a download page and a result. That step is the one a window can take off you entirely, and it is what the Verify tool is for.

Click Verify in the sidebar — the green check badge — and a segmented control offers two modes. Against a Checksum is the one for a published value: drop the file in, paste the hexadecimal string, and the algorithm is worked out from how many characters you pasted, so there is nothing to declare. The verdict appears underneath as a green seal and a sentence. Verifying a download walks that route with a real publisher's checksum.

File vs. File is the other half, for when nobody published anything and you simply have two copies — the original and the one that landed on the NAS, or yesterday's export and today's. Two drop wells sit side by side with a swap control between them, each showing the file's name and size, and the answer is again a sentence rather than two digests: Files are identical, verified byte for byte with the algorithm named underneath. Comparing two files covers the cases where the names differ and the bytes do not.

Either way you are reading one sentence rather than proofreading hexadecimal, which matters more than it sounds: a mismatch in the middle of a digest is exactly the kind of thing a tired person scrolls past.

Which parts are free, and which you unlock

Worth knowing before you go looking for a control that is not yours yet. Hashing text you type is free — open Text, type or paste anything, and all eight digests resolve as you type, with a byte count underneath and a Copy All button beside it. That is the whole of hashing text on a Mac, at no cost and with no decision to make.

The two tools that work on files are separate one-time unlocks: Files for hashing things on disk, and Verify for checking one against a value or against another file. They are independent, so you can buy one, the other, or both, and there is no subscription attached to either. If you want to see the arithmetic before you unlock anything, type a string into Text or into the SHA-256 generator in a browser tab here — both hash what you type, free, and they are genuinely the tool for an API key, a config line or a value somebody sent you. Neither of them reads a file: a file on disk is what Files and Verify are for, and so is the rest of it — a hundred thousand files, a run you need to pause, a manifest you will check again next year.

Troubleshooting

The app cannot see the file I want

That is the sandbox, and it is the trade you make for an App Store app: the window reads what you hand it and nothing else. So hand it something — drag the file in, or pick it through the add button — rather than waiting for the app to find its own way there. A folder you check regularly is worth granting once, which permission denied when hashing a folder walks through in System Settings.

My digest does not match the one I was sent

Then the two were computed over different bytes, which is nearly always a different file rather than a different program: a partially downloaded copy, a (1) duplicate, a file still being written, or a path that resolved somewhere you did not expect. If one of the two values came from hashing typed text rather than a file, a trailing newline is almost certainly the culprit — why two tools give different hashes runs through the causes in order.

I only have the checksum, not the algorithm

You do not have to work it out. Expand the file's row, which puts all eight digests on screen at once, and find the one whose length matches the value you were handed — 8 characters for CRC32, 32 for MD5, 40 for SHA-1, 96 for SHA-384. Two lengths are genuinely ambiguous: 64 characters is SHA-256 or SHA3-256, and 128 is SHA-512 or SHA3-512. The expanded row shows both candidates, so read across them rather than guessing.

The file is enormous and I do not want to sit here

You do not have to sit and guess how it is going. Live throughput and an estimated time remaining are on screen while the file streams, and the status bar along the bottom counts off what has finished, so a slow disk looks different from a stalled job. A long run can also be paused mid-file and picked up from the exact byte it stopped at, which is what you want when you need the disk back or the laptop unplugged. Pausing and resuming a hash covers that, and hashing a very large file has representative timings for disk images.

Frequently asked questions

Can I hash a file on a Mac without using Terminal?

Yes. Drag the file onto the Files tool and the digest appears beside its name, ready to copy with one click — no commands, no flags, and every other algorithm for that file one chevron away. If what you actually want is a yes-or-no against a published value rather than a string to read, Verify takes the file and the pasted checksum and answers with a sentence. The digest is identical to one produced any other way, because it depends only on the file's bytes and not on what read them.

Does macOS have a built-in checksum tool with a window?

No. There is no graphical checksum utility anywhere in macOS — nothing in the Finder, nothing in the Get Info panel, nothing in Disk Utility that will show you a file's SHA-256. The tools the system ships for it have no window at all, so a window is something you add: drop the file on the Files tool and the digest is there on the row beside its name.

Is a drag-and-drop hash as accurate as shasum?

Exactly as accurate. A hash function has no settings and no tolerances — the same bytes always give the same digest, whatever read them — so either two tools agree character for character or one of them is defective. You can settle that yourself in about thirty seconds: type abc into the free Text tool and read the SHA-256 row against the value NIST publishes for that input. Checking that a hashing tool is telling the truth walks through it.

Do I have to pay to hash a file without Terminal?

Hashing text you type is free, in the app’s Text tool and in the free text calculators on this site. Reading a file off disk is the paid half: Files for hashing files and folders, and Verify for checking one against a published value or against another file. They are independent one-time unlocks with no subscription attached, so you can buy one, the other, or both. What they add beyond the digest is everything around it — batches, live throughput, pause and resume from the exact byte, exported manifests, and a verdict instead of a comparison.

Can I hash a whole folder without the command line?

Yes — drop the folder in and every file underneath it is queued and hashed in turn, with a count of progress along the bottom. You get one digest per file rather than a single digest for the folder, which is what you want in nearly every case, since it tells you which file changed rather than only that something did.

Is hashing in a window slower than typing a command?

Not in any way you will notice. Both are limited by how fast the disk can supply bytes rather than by the arithmetic, which runs at roughly 2 GB/s for SHA-256 on Apple Silicon, and the file is read exactly once however many digests you asked for. Where the difference shows up is in the work around the hashing — queueing a batch, watching the throughput, pausing a long run and resuming from the same byte, and producing a list at the end.