Verify Kali Linux ISO Checksum on Windows 11 & 10 for free without software

Logeshwaran

To verify a Kali Linux ISO on Windows, open Command Prompt, type certutil -hashfile followed by the path to your ISO and SHA256, press Enter, and compare the 64-character result against the official hash shown under the sum button on the kali.org download page. If the two strings match, your download is intact and unaltered. You do not need to install anything — certutil ships with every copy of Windows 11 and Windows 10, and PowerShell's Get-FileHash does the same job with cleaner output. This page walks through six ways to do it, from the two built-in commands to full signature verification, and what to do when the hash does not match.

⚡ Quick Answer

Command Promptcertutil -hashfile "C:\Users\YOU\Downloads\kali-linux-2026.2-installer-amd64.iso" SHA256

PowerShellGet-FileHash "$env:USERPROFILE\Downloads\kali-linux-2026.2-installer-amd64.iso"

Compare the output with the hash under the sum button at kali.org/get-kali. Case does not matter; every character does. Full steps in Method 1, and the stronger signature check in Method 6.

🔬 How this was tested

Every command on this page was run against a real Kali Linux 2026.2 installer ISO, not copied from documentation:

  • Windows 11 25H2, build 26200.8875 — certutil, Get-FileHash, 7-Zip 24.x context menu, WSL sha256sum
  • Windows 10 22H2, build 19045 — certutil and Get-FileHash produce identical hashes to Windows 11
  • The failure case: a half-finished download renamed from .crdownload to .iso hashed without a single complaint — certutil happily fingerprints an incomplete file. The mismatch against the official value was the only thing that exposed it.

Why Jake almost booted a stranger's operating system

Jake runs a small mobile phone shop. A customer came in convinced her laptop was hacked, and Jake — who has been slowly teaching himself security basics — decided the shop bench needed a proper Kali Linux machine for jobs like that. The shop broadband is slow, so he grabbed the torrent from the Kali download page and let it run overnight. Next morning the ISO was sitting in his Downloads folder, and he had a USB stick ready.

Ethan stopped him with one question: "Did you check the hash?"

Jake hadn't. And it is worth spelling out what he was about to do: boot the shop's bench computer — the machine that touches customer phones and customer data — from a security operating system assembled out of file pieces sent to him by dozens of anonymous computers on a torrent swarm. If even one of those pieces had been altered, or the download had silently dropped a chunk, he would never know until something broke. Or worse, until nothing visibly broke at all.

The fix takes under two minutes and uses nothing but tools already on his Windows PC. That is what the rest of this page covers — every way to do it, which one to actually use, and the honest limits of what a checksum can and cannot prove.

What a checksum actually proves

A checksum — more precisely a cryptographic hash — is a fingerprint for a file. A hash function reads every byte of the file and boils it down to a short fixed-length string. For SHA-256, the algorithm Kali uses, that string is always 64 hexadecimal characters, whether the input is a 4 GB ISO or a three-word text file.

Two properties make it useful. First, the same file always produces the same hash, on any computer, any operating system, any tool. Second, changing even a single bit of the file produces a completely different hash — not slightly different, unrecognisably different. There is no way to make a "small" edit that produces a "close" hash.

So if the hash you compute on your PC matches the hash Kali's developers published, your copy is byte-for-byte identical to the file they built. That covers the two things that actually go wrong with big downloads:

  • Corruption. A dropped connection, a flaky Wi-Fi link, a browser that gave up quietly, a torrent that finished at 99.7%. This is by far the most common cause of a bad ISO — and of the maddening installer errors that follow.
  • Tampering. A modified ISO from an unofficial mirror, a poisoned torrent, or a compromised download link. Rare, but the entire reason it matters more for Kali than for a wallpaper pack: this file becomes an operating system with root access to your hardware.

This is not a theoretical worry. In 2016, the website of Linux Mint — one of the most popular desktop Linux distributions — was breached and its download links briefly pointed to an ISO with a backdoor baked in. The tampered file's checksum did not match the published one. People who checked, caught it. People who didn't, installed it. And in 2024 the xz-utils backdoor showed the same lesson from a different angle; our Kali 2024.2 download-links post covered how to check whether your install was affected.

🙋‍♂️ Jake's Reality Check

"The torrent came from kali.org itself. Why would I need to verify a file I got from the official site?"

Because the torrent link is official; the bytes are not. A torrent file from kali.org just tells your client what the finished file should look like. The actual data arrives from other people's computers. BitTorrent does its own piece-level checking, which is good, but client bugs, disk errors and premature stops still happen — and a direct browser download has no integrity checking at all. Thirty seconds of certutil settles it either way.

First, get the official hash from the right place

Before you hash anything, you need the value to compare against — and it must come from Kali's own site over HTTPS, not from wherever the ISO itself came from. Two official places carry it:

1. The download page. Go to kali.org/get-kali, find the exact image you downloaded (Installer, Live, or NetInstaller, 64-bit or otherwise), and click the small sum button next to it. The page reveals the SHA-256 value for that image. Select it and copy it.

2. The SHA256SUMS file. Kali publishes a plain-text list of hashes for every image in a release at cdimage.kali.org/current/SHA256SUMS, alongside a signature file called SHA256SUMS.gpg. You will want both of these for Method 6; for a quick manual check the download page's sum button is enough.

Match the file name exactly. The installer image (kali-linux-2026.2-installer-amd64.iso, roughly 4 GB) and the live image (kali-linux-2026.2-live-amd64.iso) are different files with different hashes, and comparing your installer against the live image's hash is one of the two most common causes of a false alarm. Kali releases roughly quarterly — 2026.2 is current as of this update — so also make sure you are not reading the hash for a newer release than the ISO you actually have on disk.

Method 1 — certutil in Command Prompt (no software, works everywhere)

This is the method the 2017 version of this post taught, and it still works on every supported Windows — 11 and 10 alike, no differences between them. Certutil is a certificate-management tool that has shipped with Windows for decades; its -hashfile switch computes file hashes as a side job.

The steps

Step 1. Open Command Prompt. Press Win + R — that keyboard shortcut opens the Run box, a small dialog that launches programs by name — type cmd and press Enter. No administrator rights needed; hashing a file only reads it.

Step 2. Type the command. The old post had you cd through drives and folders to reach the file first. Skip all of that — just give certutil the full path, in quotes:

certutil -hashfile "C:\Users\Jake\Downloads\kali-linux-2026.2-installer-amd64.iso" SHA256

The quotes matter: a path containing spaces (like C:\New Downloads\) breaks the command without them. The laziest reliable way to get the path right is to type certutil -hashfile  with a trailing space, then drag the ISO from File Explorer and drop it onto the Command Prompt window — Windows pastes the full quoted path for you — then add a space and SHA256.

Step 3. Press Enter and wait. On an SSD a 4 GB image takes around 10 to 30 seconds; on an old hard drive it can take a couple of minutes, because the entire file has to be read from disk. The cursor just blinks while it works — that is normal, not a hang. The output looks like this:

SHA256 hash of C:\Users\Jake\Downloads\kali-linux-2026.2-installer-amd64.iso:
b0c4f9e7a1d2...<64 hex characters>...8f3a
CertUtil: -hashfile command completed successfully.

Step 4. Compare it against the official value from the download page. Do not eyeball all 64 characters — humans are terrible at that. Check the first six and the last six; the avalanche property of SHA-256 means any real difference changes the string beyond recognition, so a partial match of both ends with the correct length is a match in practice. If you want a machine to do the comparison instead, that is exactly what Method 2 is for.

Certutil errors, decoded

  • "The system cannot find the file specified." The path is wrong — a typo, a missing .iso extension (File Explorer hides known extensions by default), or the file lives in another folder. Use the drag-and-drop trick above and it goes away.
  • "The filename, directory name, or volume label syntax is incorrect." Almost always unquoted spaces in the path.
  • "Access is denied." Another program has the file locked exclusively — usually your torrent client still seeding, or an antivirus scan mid-flight. Close the torrent client and retry.
  • The hash prints with no error but does not match anything. You may be hashing the wrong algorithm. If you omit SHA256, older Windows 10 builds default certutil to SHA-1, which produces a 40-character value that will never match Kali's 64-character SHA-256. Always state the algorithm explicitly.

Method 2 — Get-FileHash in PowerShell (the best default)

PowerShell is the newer of Windows' two command lines, and its hashing command was designed for this job rather than moonlighting at it. Right-click the Start button and choose Terminal on Windows 11 (or Windows PowerShell on Windows 10), then run:

Get-FileHash "$env:USERPROFILE\Downloads\kali-linux-2026.2-installer-amd64.iso"

$env:USERPROFILE is a variable that expands to your own user folder, so this exact line works no matter what your account is called — adjust only the file name. Get-FileHash uses SHA-256 by default, so there is no algorithm to remember and no silent SHA-1 trap. The output is a tidy table with the algorithm, the hash, and the path.

Let PowerShell do the comparing

The real advantage: PowerShell can compare the strings for you, which eliminates the eyeball step entirely. Paste the official hash from the download page into this line where indicated:

(Get-FileHash "$env:USERPROFILE\Downloads\kali-linux-2026.2-installer-amd64.iso").Hash -eq "PASTE_OFFICIAL_HASH_HERE"

It prints exactly one word: True or False. The -eq comparison in PowerShell is case-insensitive by default, so it does not matter that Get-FileHash prints uppercase while kali.org publishes lowercase. True means the file is verified. False means go to the mismatch section.

✅ Why this is the one to use

Get-FileHash defaults to the right algorithm, outputs cleanly, and the -eq one-liner replaces human comparison with a True/False answer. Certutil is the better story for very old machines and locked-down environments, but on any normal Windows 11 or 10 PC, Method 2 is the recommendation. Everything else on this page is either a convenience (7-Zip), a special situation (WSL), or a stronger guarantee (GPG).

Method 3 — 7-Zip's right-click menu (if you already have it)

Do not install anything just to hash a file — the built-in tools above make that pointless. But 7-Zip is already sitting on an enormous number of Windows PCs for opening archives, and it bundles a hash tool in the right-click menu.

Right-click the ISO in File Explorer. On Windows 11 the modern menu hides most third-party entries, so click Show more options (or press Shift + F10) to reach the classic menu — this extra step is a Windows 11 quirk, not a 7-Zip problem; on Windows 10 the entry is right there. Then choose CRC SHA → SHA-256. A window pops up with the hash once the file has been read.

Newer 7-Zip versions add a CRC SHA → Checksum information entry that shows several algorithms at once. Either way, you still compare against the official value by eye — 7-Zip will not do the True/False comparison for you, which is why Method 2 remains the better default even when 7-Zip is installed.

Method 4 — WSL and sha256sum (the Linux way, on Windows)

If you have the Windows Subsystem for Linux installed — and if you are downloading Kali, there is a fair chance you do — you can use the exact command Kali's own documentation uses. Your Windows drives appear inside WSL under /mnt, so from PowerShell:

wsl sha256sum /mnt/c/Users/Jake/Downloads/kali-linux-2026.2-installer-amd64.iso

Note the flipped path convention: C:\Users\... becomes /mnt/c/Users/... with forward slashes, and Linux paths are case-sensitive. The payoff of the Linux route is automatic checking against Kali's own list. Download the SHA256SUMS file from cdimage.kali.org into the same folder as the ISO, then run:

cd /mnt/c/Users/Jake/Downloads && sha256sum -c SHA256SUMS --ignore-missing

The -c switch reads the list and checks every file it finds; --ignore-missing stops it complaining about the dozen other Kali images you did not download. The output is a single line: the file name followed by OK. This is also precisely the skill you will use later on Kali itself, where sha256sum is the native tool.

Method 5 — hash checker apps, and why you should skip them

Search for "checksum tool Windows" and you will find a pile of small utilities — OpenHashTab, QuickHash, HashCalc and friends — that add a Hashes tab to file Properties or wrap the job in a window with a Compare box. Some are genuinely well made. OpenHashTab, for instance, is open source and pastes the expected hash for you, colouring the result green or red.

Here is the honest assessment: for this job, do not bother. Half the internet's tutorials tell you to install software to verify a file whose entire problem is that you cannot yet trust what you install — and downloading a random hashing utility from a software portal to verify a Kali ISO is a genuinely absurd chain of trust. The built-in tools compute the identical mathematics. A GUI tool earns its place only if you verify downloads weekly and want the Properties-tab convenience; install it from its official source, and never for a one-off.

The same logic applies to online "hash checker" websites, with an extra problem: you cannot upload a 4 GB ISO to a web page in any sane amount of time, and you should not trust the answer if you could.

Method 6 — verify the signature, not just the hash

Time to name the limit of everything above, because almost no tutorial does. A checksum proves your file matches the published value. It cannot prove the published value is legitimate. If an attacker ever compromised the download page itself — the Linux Mint scenario — they would publish the hash of their tampered ISO right next to it, and your certutil check would come back as a perfect match. Matching a forgery is still a match.

The answer is a digital signature. Kali signs the SHA256SUMS file with a private key that only the Kali development team holds. Anyone can fetch the matching public key and mathematically confirm that the checksum list was signed by that key and not altered since. A website intruder cannot fake that signature without stealing the private key, which does not live on the web server.

Doing it on Windows with Gpg4win

Step 1. Install Gpg4win from gpg4win.org — the standard OpenPGP suite for Windows. (Yes, this method breaks the "no software" promise; it is the one job the built-in tools cannot do.)

Step 2. Download three files into one folder: your ISO, SHA256SUMS, and SHA256SUMS.gpg from cdimage.kali.org, plus Kali's public key from archive.kali.org/archive-key.asc.

Step 3. In PowerShell, in that folder, import the key and check its fingerprint:

gpg --import archive-key.asc
gpg --fingerprint ED65462EC8D5E4C5

The fingerprint must read 827C 8569 F251 8CC6 77FE CA1A ED65 462E C8D5 E4C5. This is Kali's current archive key — note that it changed in 2025, when the team lost access to the old repo signing key and issued this replacement, so guides showing an older fingerprint are out of date, including anything written before April 2025.

Step 4. Verify the signature, then check the ISO against the now-trusted list:

gpg --verify SHA256SUMS.gpg SHA256SUMS

You want "Good signature" in the output. A warning that the key is "not certified with a trusted signature" is normal and expected — it just means you have not personally built a web of trust to this key, which is why the fingerprint check in step 3 matters. With a good signature confirmed, compare your ISO's hash (Method 1 or 2) against the entry in SHA256SUMS, and the chain is complete: Kali's key signed the list, the list names your hash, your file produces that hash.

Should you do all this? For a home lab machine, a matching SHA-256 from the HTTPS download page is a reasonable stop. For anything professional — Jake's bench machine that touches customer devices absolutely qualifies — do the signature check once per release. It adds five minutes to something you do four times a year.

Which method should you use?

Method Installs anything? Compares for you? Use it when
1. certutil No No Any Windows, including old or locked-down machines
2. Get-FileHash No Yes (-eq gives True/False) The default. Use this one.
3. 7-Zip menu Already installed for most No You live in File Explorer and 7-Zip is already there
4. WSL sha256sum Needs WSL Yes (sha256sum -c) WSL users; matches Kali's own docs
5. Hash GUI apps Yes Yes Rarely worth it — only for frequent, repeated verifying
6. GPG signature Yes (Gpg4win) Yes, and authenticates the list itself Professional or bench machines; the strongest guarantee

The hash does not match — now what?

First: do not panic, and do not boot it. A mismatch nearly always has a boring explanation. Work down this list in order, because it is ordered by likelihood:

  • You compared against the wrong image's hash. Installer vs Live vs NetInstaller, or amd64 vs arm64. Re-read the file name character by character against the entry on the download page.
  • Version drift. Your ISO is 2026.1 but the site now shows 2026.2 hashes. Kali's current folder only carries the newest release; old release hashes live in the archived release folders on cdimage.kali.org. This one catches people who downloaded a month ago and verified today.
  • Wrong algorithm. A 40-character output means certutil computed SHA-1. Re-run with SHA256 spelled out.
  • Incomplete download. Compare your file's size in File Explorer (right-click → Properties, check the exact byte count) against the size listed on the download page. A short file is a truncated download — the browser gave up, the disk filled, or the torrent stopped early. This is the single most common genuine cause.
  • Actual corruption or tampering. If the size matches and the hash still differs, delete the file and re-download — ideally directly from kali.org over HTTPS rather than the same torrent, and via a different network if you can. If a fresh direct download from the official site also mismatches its own published hash, something is interfering with your connection or your disk is failing; at that point run the GPG check from another machine and network before trusting anything.

⚠️ What this actually breaks

Never install from a mismatched ISO "because it is probably just a glitch". A corrupted installer at best fails cleanly; at worst it half-writes a system that fails weeks later in unrelated, undiagnosable ways — and if the cause was tampering rather than corruption, you have handed over the machine entirely. The ISO cost you bandwidth. Re-downloading is always cheaper than what a bad one costs.

What the 2017 version of this post got wrong

This article was first published in 2017, for Kali 2017.2, and the core advice — certutil, SHA-256, compare with the official site — was right then and is right now. But rereading it for this rewrite, three things deserve an open correction rather than a quiet edit:

1. We told you to verify against the checksum file sitting next to your download. The old post suggested opening the .txt.sha256 file that arrived in the same folder as the ISO and comparing against that. That advice defeats the entire exercise. If your download source was compromised or corrupted, the checksum file that came from the same place is compromised or corrupted with it — you would be asking a possibly-bad source to vouch for itself. The comparison value must come from kali.org over HTTPS, or better, from a GPG-verified SHA256SUMS. That is the whole reason Method 6 exists.

2. We said a matching checksum means the file is "99.9% unaltered". Charming, but wrong in both directions. Mathematically, a matching SHA-256 makes accidental corruption essentially impossible — far better than 99.9%. But against a deliberate attacker who controls the page publishing the hash, a matching checksum alone proves nothing at all. The honest statement is: checksum verification is near-absolute against corruption, and only as trustworthy as the place you got the reference value from against tampering.

3. The steps were numbered 1, 2, 7, 8. For eight years. Nobody wrote in. We fixed the numbering by deleting the folder-navigation steps entirely — quoting the full path was always the better way.

After the checksum: USB, first boot, and what breaks next

A verified ISO is step one of an install, so here is the thirty-seconds-later question answered in advance. Write the ISO to USB with Rufus or Etcher — and know that you cannot simply re-run certutil against the USB drive afterwards to double-check it. Writing tools alter the byte layout (partition tables, padding beyond the image's end), so the drive will not hash to the ISO's value even when the write was perfect. Trust the writing tool's own verify pass instead; Rufus offers one at the end. This also answers the reverse question: a "failed" hash on a USB stick you wrote is meaningless, not alarming.

Once Kali is running, a few of our other guides cover the things that genuinely trip up new installs, and they are the reason this page stops here rather than duplicating them:

One more note for Jake's situation specifically: the bench machine he freed up for Kali was an older Windows 10 box. Windows 10 has been out of free security support since October 2025 — enrolled machines get Extended Security Updates until October 2027 — so repurposing an aging Windows 10 PC as a dedicated Kali bench machine, and moving the day-to-day work to supported hardware, is a genuinely sensible use for one.

FAQ — Kali checksum verification on Windows

Does certutil come preinstalled on Windows 11 and Windows 10?

Yes. Certutil is part of every Windows 11 and Windows 10 installation, all editions including Home. There is nothing to download or enable — open Command Prompt and it is there.

Which is better, certutil or Get-FileHash?

Get-FileHash, for most people. It defaults to SHA-256 so you cannot accidentally compute the wrong algorithm, and its -eq comparison turns verification into a True/False answer instead of eyeballing 64 characters. Certutil's advantage is ubiquity — it exists on ancient and locked-down systems where PowerShell may be restricted.

The hash on my PC is uppercase but kali.org shows lowercase. Is that a mismatch?

No. Hexadecimal is case-insensitive: B0C4 and b0c4 are the same value. Get-FileHash prints uppercase, kali.org publishes lowercase, and PowerShell's -eq comparison ignores case automatically. Only the characters themselves matter.

How long does hashing a 4 GB ISO take?

Roughly 10 to 30 seconds on an SSD, and up to a few minutes on an older mechanical hard drive. The limit is how fast the disk can read the file, not the mathematics. A blinking cursor with no output during that time is normal.

Why did my hash come out only 40 characters long?

That is a SHA-1 hash, which means the algorithm was not specified. On some Windows 10 builds, certutil without an explicit algorithm defaults to SHA-1. Re-run the command with SHA256 stated at the end and you will get the 64-character value Kali publishes.

Is MD5 still okay for checking a Kali download?

No. MD5 has been cryptographically broken for years — attackers can construct different files with the same MD5 — and Kali does not publish MD5 values anyway. Any tutorial telling you to MD5-check a modern Kali ISO is outdated. Use SHA-256.

The checksum file that came with my torrent matches my ISO. Am I safe?

Not on that evidence alone. A checksum file downloaded from the same source as the ISO can only prove the two files agree with each other — if the source was bad, both are bad together. Compare against the value on kali.org over HTTPS, or verify the GPG-signed SHA256SUMS file for a real guarantee.

Where is the official Kali SHA256 value published?

Two places: under the small sum button next to each image on kali.org/get-kali, and in the SHA256SUMS file at cdimage.kali.org/current/ for the newest release, with older releases in their own dated folders. The SHA256SUMS file is accompanied by SHA256SUMS.gpg, its signature.

What does CertUtil say when the file path is wrong?

The system cannot find the file specified. It means the path has a typo, the file is in a different folder, or the real name differs — often because File Explorer hides the .iso extension. Drag the file from Explorer into the Command Prompt window to paste the exact quoted path.

Can I verify the USB stick after writing the ISO to it?

Not by hashing the drive with certutil — writing tools change the byte layout, so the drive will never reproduce the ISO's hash even after a perfect write. Verify the ISO before writing, then use the writing tool's own verification pass; Rufus offers one when it finishes.

Do I need to verify again after copying the ISO to another drive?

Strictly, a correct copy has an identical hash, so no. Practically, re-running Get-FileHash after copying to an external drive takes seconds and catches the rare copy error or failing drive before you are standing at a machine with a bad installer. Cheap insurance; do it for anything important.

Is a matching SHA256 enough, or do I need the GPG signature check too?

A matching SHA-256 against the value on kali.org over HTTPS is reasonable for a personal lab machine. The GPG signature check additionally proves the checksum list itself came from Kali's developers, which protects you even if the website were compromised. For any machine used professionally, do the signature check once per release.

Does verifying work the same on Windows 11 and Windows 10?

Yes — certutil, Get-FileHash and the PowerShell comparison line are identical on both. The only difference on Windows 11 is cosmetic: third-party context-menu entries like 7-Zip hide behind Show more options in the right-click menu.

Revision note. Originally published 11 October 2017 for Kali 2017.2; last touched 2019. Now updated on 1 August 2026 against Kali Linux 2026.2 on Windows 11 25H2 (build 26200.8875) and Windows 10 22H2. Corrections from the original are stated openly above: we no longer suggest verifying against the checksum file bundled with the download, the "99.9% unaltered" claim is replaced with an accurate statement of what a checksum does and does not prove, and GPG signature verification — absent from the original — is now covered as the stronger check, so happy breaking not yours, others!

Related