Hash Generator
SHA-256, SHA-512 and MD5 for text or files — computed locally with WebCrypto.
Or drop a file here to hash it — files never upload anywhere.
MD5 and SHA-1 are shown for checksums and legacy interop only — both are cryptographically broken. Use SHA-256 or SHA-512 for anything security-sensitive.
SHA-256 of 43 input bytes. All four digests update live below — hex and base64 forms of the same bytes.
How it works
A cryptographic hash function maps any input — a sentence, a 4 GB ISO — to a fixed-size digest that acts as a fingerprint. Change one bit of the input and roughly half the output bits flip, which is why hashes are the backbone of file integrity checks, content-addressed storage, git object IDs and digital signatures. This tool computes MD5, SHA-1, SHA-256 and SHA-512 simultaneously over the same input, so you can compare a published checksum in whatever algorithm the publisher chose.
The SHA family digests are produced by crypto.subtle.digest, the WebCrypto API shipped in every modern browser — the same native code paths your operating system uses, not a JavaScript reimplementation. MD5 is no longer exposed by WebCrypto precisely because it is cryptographically broken, so a compact implementation of the public-domain RFC 1321 algorithm is inlined here for checksum compatibility. Both paths run entirely in your tab: text is encoded as UTF-8, files are read with FileReader into an ArrayBuffer, and nothing is sent over the network.
Each algorithm shows two encodings of the identical digest bytes. Hex is the lingua franca of checksums — lowercase by convention, with an uppercase toggle for tools that expect it. Base64 is what you will meet in HTTP headers, Subresource Integrity attributes and many cloud APIs. If a verification fails, check encodings first: comparing a hex digest against a base64 one will never match even when the underlying bytes are identical.
A practical rule of thumb for choosing: SHA-256 is the default for new work — universally supported, collision-resistant, and fast on modern hardware. SHA-512 is actually faster than SHA-256 on 64-bit CPUs for large inputs and gives a wider security margin. SHA-1 should only appear when an existing protocol demands it (old git repositories, legacy APIs), and MD5 only to verify a checksum someone else already published. None of the four are appropriate for password storage — that job belongs to deliberately slow functions like Argon2id.
Frequently asked questions
Is it safe to hash sensitive files here?
Yes — everything is computed locally. SHA-1, SHA-256 and SHA-512 run through your browser's built-in WebCrypto API (crypto.subtle.digest), and the MD5 implementation is a small inline JavaScript function. The file is read with FileReader into memory in your tab and never transmitted. Open the network panel in devtools while hashing: you will see zero requests fire.
Why is MD5 still included if it's broken?
MD5 collisions can be generated in seconds, so it must never be used for signatures, passwords or any security decision. But it is still everywhere as a non-adversarial checksum: package mirrors, S3 ETags, legacy databases and download verification pages all publish MD5 sums. The tool includes it for interoperability and labels it as broken so nobody mistakes it for a secure choice.
What is the difference between hex and base64 output?
They encode the same digest bytes differently. Hex uses two characters per byte, so a SHA-256 digest is 64 hex characters; base64 packs roughly three bytes into four characters, giving 44 characters for the same digest. Hex is the convention for checksums and git-style identifiers, while base64 appears in HTTP headers like Content-MD5 and in Subresource Integrity hashes (which use base64 of SHA-384 by default).
Can I use this to hash passwords?
No — and neither should any system you build. Plain cryptographic hashes are designed to be fast, which is exactly wrong for passwords: an attacker with a GPU can try billions of SHA-256 candidates per second. Password storage needs a deliberately slow, salted, memory-hard function like Argon2id, scrypt or bcrypt. Use this tool for file integrity, cache keys, content addressing and deduplication instead.
Why do my hashes differ from another tool's for the same text?
Almost always an invisible input difference: a trailing newline, Windows CRLF versus Unix LF line endings, a UTF-8 BOM at the start of a file, or different Unicode normalization of accented characters. Hashes are bit-exact, so a single different byte produces a completely unrelated digest. Hash the raw file via drag-and-drop rather than copy-pasting its contents to rule out editor transformations.
Built by FORG — AI cost observability for agentic coding. Free tools, no signup, nothing leaves your browser.
Learn about FORG