💿 Verify an Arch ISO before you install it

An installer image is the most trusted thing you will ever run: it partitions your disk and it writes your bootloader. Check it before it gets that chance. Nothing here is uploaded — this site is static files with no server to upload to, and the hashing happens in your browser.

The one rule this page is built around. Never take the image and its checksum from the same host. If one server gives you both, a server that lies about the image can hand you a checksum that matches the lie, and every check you run will pass. So: one mirror for the image, two different mirrors for the checksum, and the two have to agree with each other before either is believed.

1Download the image

The authority for what Arch has released is archlinux.org/download. Start there. Everything below is a convenience, not a replacement.

Your randomly selected image mirror, nearest tier first (guessed region: —):

Image mirror — — (—)
Start the download here — it comes straight from the mirror, not through this site.

⬇️ Download the ISO 🔏 Download the signature 📁 Browse the directory

About 1.2 GB. Nothing is proxied through this site — there is no server here to proxy it. Get the .sig too; you need it for step 4.

What "closest" means here. Continent, inferred from your browser's time zone. It is not a latency measurement — a static page is not allowed to time a cross-origin request it cannot read, so claiming to have measured one would be a lie. Continent is a good enough proxy for picking a nearby mirror.

2Get the checksums from somewhere else

Two mirrors, neither of them the one that gave you the image, and where possible in different countries. Open both, copy the contents, and paste them into step 3.

Why two and not one. One alternative source protects you against a single compromised or misconfigured mirror. Two lets the page detect the case where the sources disagree, which is the signal that something is actually wrong rather than merely unverifiable.

Prefer the terminal? Same idea, three commands:

curl -O https://<mirror-a>/iso/latest/sha256sums.txt
curl -O https://<mirror-b>/iso/latest/sha256sums.txt -o sha256sums.b.txt
diff sha256sums.txt sha256sums.b.txt && sha256sum -c sha256sums.txt --ignore-missing

3Hash your file and compare

Filename to look for in the checksum lists

Filled in from the file you pick. Change it if the release you downloaded differs from the one the list names.

Paste sha256sums.txt from source 1 Paste sha256sums.txt from source 2

4Check the signature. Do not skip this.

A matching hash proves your file is what those mirrors serve. It does not prove Arch published it. Only the GPG signature does that, because only the release engineer holds the key that makes one.

Arch release signing key:

—

Compare that against archlinux.org/download as well. A fingerprint you only ever saw on one website is a fingerprint you have not really checked.

# fetch the key from Arch's own web key directory, not from a mirror
gpg --auto-key-locate clear,wkd -v --locate-external-key pierre@archlinux.org

# verify
gpg --verify archlinux-x86_64.iso.sig archlinux-x86_64.iso

Or with Sequoia, if you prefer it:

sq network wkd search pierre@archlinux.org --output release-key.pgp
sq verify --signer-file release-key.pgp \
          --signature-file archlinux-x86_64.iso.sig archlinux-x86_64.iso

What a good signature does and does not tell you. It says the holder of that key signed this exact file. It says nothing about whether the key is still trustworthy — which is why the fingerprint matters, and why it is worth checking in more than one place.

5Write it, and mind the dual boot

Verify before writing. Writing an image you have not checked and verifying the USB afterwards tells you the copy succeeded, not that the original was genuine.

lsblk                       # find the device. Get this wrong and you lose a disk.
sudo dd if=archlinux-x86_64.iso of=/dev/sdX bs=4M status=progress oflag=sync

/dev/sdX is not a real device name. Substitute the one lsblk showed you, and check it twice. dd will not ask.

Dual booting

Do not let the installer touch the existing ESP. Windows and Arch can share one EFI system partition, but only if you mount it and install to it rather than reformatting it. Formatting the ESP removes the Windows boot entry.
Turn off Windows Fast Startup before you shrink anything. Fast Startup leaves NTFS in a hibernated state; resizing or mounting it read-write from Linux in that state corrupts it.
Secure Boot stays on if you enrol your own keys. Disabling it for Arch also lowers the bar for the Windows install sitting next to it. The Secure Boot section covers enrolling your own keys with a signed UKI.
BitLocker will demand a recovery key. Changing the boot configuration changes the TPM measurements. Suspend BitLocker before installing, and have the recovery key written down somewhere that is not the machine you are about to repartition.
Full walkthrough: Dual boot in the wiki and docs/06-dual-boot.

On ARM

There is no single Arch ISO for aarch64. Arch Linux ARM ships per-board rootfs tarballs, and the boot path is U-Boot or the board's own firmware rather than a UEFI ISO you write to a stick — so steps 1 to 3 do not apply in the same shape. Use the Arch Linux ARM image for your board and verify its published checksum the same way: from a host other than the one that served it. The generator's architecture option branches the guide accordingly.

Nothing here needs this page. Every check above is a terminal command, and the commands are the authority. This page exists to make the two-source rule easy to follow, not to become another thing you have to trust.