HashShift · Runs in your browser · The Altar by Misfit Mindset · Shift

About HashShift

The ISO you downloaded should match the SHA-256 on the vendor page. HashShift computes SHA-256 and SHA-1 of files or text in the browser so the bytes never upload 'to be hashed.' Use it to verify a download, to compare two copies after SplitShift join, to fingerprint a string. Do not use it as encryption, as a password store, or as a way to 'hide' a file. Hashes are public fingerprints. SHA-1 is here because old manifests still speak it; prefer SHA-256 when you have a choice. MD5 is not the star of this booth even if the internet still types it.

Drop a file or paste text. Read the hex digest. Compare case-insensitively with the published value. A mismatch means the file is not the file, or you hashed a different layer (the ZIP instead of the ISO inside). That mistake is more common than bitrot. Hashing in-tab uses Web Crypto or a wasm hash; large files stream. A 4 GB ISO is slow in a tab but possible if memory behaves.

When not to use it: you needed HMAC with a key, a bcrypt password hash, or a git blob hash with the header. Those are different functions. Also skip it if you were about to upload a secret document to an online hasher — that is how secrets become someone else's training set. Local is the point.

SHA-1 collisions exist in the lab and in some PDF tricks. Do not use SHA-1 as proof of integrity for a new system. It is a compatibility reader. For passwords, do not hash with SHA-256 and call it storage; use a password hasher. The checksums guide on the site is the longer argument.

How to use it

  1. Drop a file or paste the text you want fingerprinted.
  2. Read the SHA-256 (and SHA-1 if you are matching an old manifest).
  3. Compare to the vendor-published digest; ignore hex case.
  4. If they differ, hash the correct layer (inner ISO vs outer ZIP) before you panic.
  5. For a join-after-split, hash the reconstructed file against the original digest you saved.

Worked example

linux.iso, 4.7 GB, vendor says SHA-256 starts 3c7a… You drop the ISO in HashShift. After a wait, the digest matches. You install. A second file is firmware.zip; the vendor hashed the inner bin. Your first hash of the ZIP mismatches, the inner file matches. You almost re-downloaded for no reason. Neither file uploaded to a hasher. The inner firmware bin matching after the ZIP mismatched is the usual false alarm, not bitrot.

Limits — when not to use HashShift

Privacy

HashShift hashes in the browser. Files and text stay on the device. That is the difference from 'upload to hash' sites. The digest you paste into a ticket is not the file, but the filename still might be sensitive — watch that.

Full policy: Shift Privacy Policy. Questions: [email protected].

Questions people actually ask

SHA-256 or SHA-1?

SHA-256 for anything you control. SHA-1 only to match a published SHA-1. Do not design a new pipeline on SHA-1. SHA-256 for anything you control; SHA-1 only when a vendor page still publishes that string.

Why not MD5?

This booth leads with SHA-256 and SHA-1. MD5 is broken for collision resistance. If an old README only lists MD5, treat it as a weak hint, not a signature. MD5 is broken for collisions; if an old README only lists it, treat it as a weak hint, not a signature.

Can I hash a password to store it?

Not with a single SHA-256. Use a password hashing scheme. HashShift is for integrity of files and strings, not for authentication storage. A single SHA-256 is not password storage; use a real password hasher for authentication databases.

The hash changes every time I save the file from Word.

Yes. Bytes changed. Hashes are exact. That is a feature. Export a canonical PDF if you needed a stable digest. Hashes are exact; a different export is a different file even when the words look the same on screen.

Longer guide: Checksums And Base64

Related tools: Base64Shift · PassShift · SplitShift
Guides · All Shift tools · About · Contact