Skip to content

All tools (41)

JSON 6
Time & Date 4
Encoding & Decoding 4
Generators 3
Text & Data 4
Logs & Debugging 1
Config & Infra 3
Security & Hashing 4
Color & Design 5
Numbers & Bits 3
Web & Markup 4

Nothing leaves the cave.

Nothing you paste ever leaves your device. There is no server to send it to.

How you can check →
DevToolsCave

    This tool runs entirely in your browser. Nothing you paste is uploaded.

    How you can check →

    File Checksum

    Security & Hashing

    Checksum any file entirely in your browser, streamed in chunks so even a multi-gigabyte ISO or archive never crashes the tab. Nothing is uploaded.

    Algorithms

    Equivalent OS command

    Drop one or more files here, or

    Nothing is uploaded — hashing happens in this tab. You can also drop a SHASUMS256.txt or *.sha256 manifest here to check a whole batch at once.

    Drop a file above to see its checksum for every selected algorithm, streamed with a live progress bar — even for files too large to fit in memory all at once.

    What a file checksum proves — and what it doesn't

    A checksum is a fixed-length fingerprint of a file's exact bytes: change even one bit and the checksum changes completely. Comparing a freshly computed checksum against a value the publisher printed lets you confirm your download arrived intact. What it cannot do is guarantee the file is safe or authentic — if the checksum was published on the same page as the download, an attacker who tampered with one could just as easily have tampered with the other. A checksum is trustworthy evidence only when you got it from a source independent of the download itself, such as a signed release notes page or a separate announcement.

    Why large files crash other browser-based checksum tools

    The Web platform's built-in hashing API, crypto.subtle.digest, is one-shot by specification — it needs the entire input in a single ArrayBuffer before it can compute anything. Browsers cap how large a single buffer can be, typically in the low gigabytes, so a tool built directly on that API either crashes or silently hangs on a multi-gigabyte ISO or virtual-machine image — exactly the files people actually verify checksums for. This tool instead reads the file through File.stream() in fixed chunks and feeds each chunk into a hand-written, incremental implementation of every selected algorithm, so only one small chunk is ever in memory at a time. The file size stops being a ceiling.

    Verifying a whole release with SHASUMS256.txt

    Most projects don't publish one checksum — they publish a manifest file, often named SHASUMS256.txt or ending in .sha256, with one <hex> <filename> line per release artifact. That's the same format sha256sum -c reads on the command line, and it is what most of this category's tools do not accept at all. Drop the manifest onto this page and every entry is matched to a queued file by name, producing an OK or FAILED verdict per file plus a note for anything still missing from the queue.

    The OS commands this replaces

    The same digests these algorithms produce are what sha256sum and shasum -a 256 print on Linux and macOS, and what Get-FileHash and certutil -hashfile print on Windows — this tool exists for when installing or reaching for a terminal isn't convenient, not to replace them.

    Common use cases

    • Verifying an ISO, installer or archive against a checksum a project publishes
    • Checking that a large file transferred without corruption
    • Generating a checksum to hand to someone else for their own verification
    • Hashing several files at once with the same algorithm selection

    Frequently asked questions

    Does this upload my file anywhere?
    No. The file is read in your browser by a Web Worker, hashed in fixed-size chunks as it streams off disk, and never sent anywhere. The privacy receipt below the tool measures the actual network requests made by this page, so the claim is checkable in your own Network tab rather than something you have to trust.
    Why does this not crash on a multi-gigabyte file?
    Most browser-based checksum tools read the whole file into one ArrayBuffer before hashing it, because crypto.subtle.digest only accepts one shot. Browsers cap a single buffer at a few gigabytes, so a large ISO or archive crashes the tab. This tool streams File.stream() through hand-written incremental hash engines instead, so it only ever holds one small chunk in memory at a time — the file size is not a ceiling.
    What does a matching checksum actually prove?
    That the bytes you have match the value you pasted — nothing more. If that value came from the same page you downloaded the file from, a match only proves the download wasn't corrupted in transit; it says nothing about whether the file itself is legitimate, since an attacker who replaced the file could just as easily have replaced the checksum next to it. A checksum is trustworthy evidence only when it came from a channel independent of the download.
    Which algorithm should I use to verify a download?
    Whichever the publisher actually gave you — verification only works if you compute the same algorithm they used. SHA-256 is the most common today and is selected by default here. MD5 and SHA-1 still turn up on older release pages; both are fine for catching accidental corruption even though neither should be trusted against a deliberate attacker.
    Can I hash more than one file at once?
    Yes — drop or select several files and they queue up, each hashed in turn with its own progress bar. Every file in the queue gets every algorithm you have selected, computed in a single pass over its bytes rather than one pass per algorithm.
    Can I cancel partway through a large file?
    Yes. Cancel actually stops the underlying read rather than just hiding the progress bar — the worker cancels its stream reader immediately, so no more of the file is touched.
    Can I verify a whole batch of files against a SHASUMS256.txt?
    Yes — drop the SHASUMS256.txt (or any *.sha256/*.md5/*.sha1 manifest) onto this page and it's parsed into a per-file report: OK for a match, FAILED for a mismatch, and a note for any manifest entry you haven't dropped yet. This is the artefact most release pages actually publish, and matching entries to queued files by name is exactly what sha256sum -c does on the command line.