Online Hash Generator Tool

Hashing gives you a compact fingerprint of data so you can detect tampering, verify downloads, compare blobs without exposing originals, and integrate with systems that expect fixed-width digests. A digest is small enough to paste into a chat message and specific enough that changing a single byte of the input changes it beyond recognition, which is what makes it useful for proving two things are identical without moving either of them.

Generate MD5, SHA-1, SHA-256, and more hashes from your text.

Benefits of hash generation

• Data integrity: Detect accidental or malicious changes by comparing digests.
• Password handling: Combine strong algorithms with salts and key derivation—never store raw passwords.
• Digital signatures: Higher-level protocols build on hashes to authenticate messages.
• Checksums: Quick integrity checks for configs, artifacts, and transferred files.
• Fingerprinting: Stable identifiers for caches, deduplication, and auditing.

Each algorithm turns arbitrary input into a fixed-length digest. Length and collision resistance determine whether a function still fits modern security expectations, and the underlying construction determines what a future weakness in one family would mean for the others.

Algorithms available on this page

• MD5: 128-bit output; fast and widely recognized but not collision-resistant for security claims.
• SHA-1: 160-bit output; deprecated for new security uses but still seen in legacy checksums and in Git object ids.
• SHA-256: 256-bit output from the SHA-2 family; a common default for integrity and signatures today.
• SHA-384: 512-bit internal state truncated to 384 bits; specified for several TLS cipher suites and certificate profiles.
• SHA-512: 512-bit output; larger state, often used when you want a wider digest or specific performance characteristics.
• SHA3-256: 256-bit output built on the Keccak sponge, a completely different construction from SHA-2, so a break in one does not imply a break in the other.
• SHA3-512: 512-bit sponge output; the widest digest here, and the slowest, because it absorbs only 72 bytes per permutation.
• CRC-32: A 32-bit checksum, not a cryptographic hash. It catches accidental corruption and is what ZIP archives, PNG chunks and gzip streams record.

Choosing between them

The right answer is usually decided for you by whatever you are interoperating with. When it is not, the shortlist is short.

• If you are checking a download, use the algorithm the publisher published. Anything else proves nothing, however strong it is.
• If you are choosing for new work, SHA-256 is the default that every language, runtime and command-line tool already has.
• Use SHA-512 when you want a wider digest, or on 64-bit hardware where it is often faster than SHA-256 despite being larger.
• Use SHA3-256 when you specifically want a construction unrelated to SHA-2 — for example when a standard requires algorithm diversity.
• Use CRC-32 only for accidental corruption. It is trivially forgeable and was never meant to resist an attacker.
• Never pick MD5 or SHA-1 for anything new. Both are here because real systems still emit them, not because they are safe.

Use this guide to produce MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-512 or CRC-32 digests from plain text or from a file, without sending anything to a server.

1. Choose text or a file — Type or paste a string, or drop a file of any type. Text hashes update automatically as you edit; a file is hashed when you press the button, with a progress bar and a working cancel.
2. Pick the algorithms you need — MD5, SHA-1, SHA-256 and SHA-512 are selected by default. Add SHA-384, SHA3-256, SHA3-512 or CRC-32, or narrow it to a single one. Every algorithm is available on the free plan.
3. Set the output format, and a key if you need one — Switch between lowercase hex, uppercase hex and Base64. To produce an HMAC instead of a plain digest, enter a key and say whether it is UTF-8, hex or Base64.
4. Copy the value, or verify one you were given — Copy any digest with one click. To check a download, paste the published checksum into the verify box: the algorithm is worked out from its length and the match is confirmed or denied straight away.

This is the single most common reason a checksum “does not match” when nothing is actually wrong. A hash is computed over bytes, and the same document can be several different byte sequences.

• Line endings: a text file saved on Windows ends each line with CRLF and on macOS or Linux with LF. Those are different bytes, so they are different digests, even though the file looks identical in every editor.
• Byte-order marks: a UTF-8 file saved “with BOM” starts with three extra bytes that you cannot see and that change the digest completely.
• Trailing newlines: most editors add one when saving. Pasting the visible content into a text box usually does not.
• Encoding: text typed here is hashed as UTF-8. A file stored as UTF-16 or a legacy code page contains entirely different bytes for the same characters.

The rule that follows is simple: when you are verifying something, hash the file itself rather than its contents pasted into a box. Use text mode for strings you are hashing on purpose — an API payload, a password you are about to salt, a value you want a stable identifier for.

Publishing a checksum next to a download lets anyone confirm the bytes they received are the bytes that were released. Doing that check is the most common reason people open a hash tool at all, and it takes four steps here.

1. Drop the downloaded file in and press Hash. The file is read on your device; nothing is uploaded, which matters because the file you are checking may be one you are not allowed to share.
2. Copy the checksum from the publisher's page or their signature file.
3. Paste it into the verify box. The algorithm is worked out from the length of what you pasted, so you do not need to know whether it is SHA-256 or MD5 — and when a length is ambiguous, such as the 64 characters shared by SHA-256 and SHA3-256, both are checked.
4. Read the verdict. A match means the file is byte-for-byte what was published. A mismatch means it is not, and the download should be repeated from a source you trust.

A checksum on the same page as the download protects you against a corrupted transfer, not against a compromised website — anyone who can change the file can change the number beside it. For that you need a signature, which is a hash the publisher has signed with a key you already trust.

A plain digest proves that data has not changed. It does not prove who produced it, because anyone can compute one. HMAC closes that gap by mixing a secret key into the hash, so only a holder of the key can produce or check a value.

• Webhook signatures: services sign each delivery so your endpoint can reject requests that did not come from them. Almost all use HMAC-SHA-256.
• API request signing: a canonical string built from the request is hashed with a shared secret and sent as a header.
• Message authentication: a value stored or transmitted alongside data so a receiver can detect tampering by anyone without the key.

Keys are not always text. A secret is often published as hex or Base64, and typing those characters in as text would key the digest with the wrong bytes and produce a value that never matches. That is why the key box asks how the key is encoded, and why it accepts UTF-8, hex and Base64. CRC-32 cannot be keyed and is left out automatically when a key is present.

Treat hashes as one-way summaries: useful for integrity, not for secrecy by themselves.

Key properties

• Output length is fixed for a given algorithm regardless of how long the input string is.
• The same input always yields the same digest when you use the same algorithm.
• A tiny change in input produces an unrelated-looking digest (the avalanche effect).
• Standard cryptographic hashes are one-way: you cannot recover the original text from the digest alone.
• SHA-256 and SHA-512 are appropriate choices when collisions must be computationally infeasible.
• Every algorithm has a defined digest for empty input, which is why an empty box still produces a value rather than nothing.

Best practices

Match the algorithm to the threat model, and never confuse encoding with encryption.

• Use SHA-256 or SHA-512 when building new systems that need collision resistance.
• Do not rely on MD5 or SHA-1 alone for passwords or certificates.
• Stay consistent: migrating algorithms later may require re-hashing or dual verification periods.
• Protect stored digests like any sensitive metadata, and combine password hashes with per-user salts and modern KDFs.
• When verifying integrity, compare digests in constant time in application code to reduce timing leaks.
• A hash is not a password hash. Passwords need a deliberately slow key derivation function such as Argon2, scrypt or bcrypt, not a fast digest.

Typical use cases

• Credential storage: Feed passphrases through a vetted KDF, then store the resulting digest—but plan upgrades as hardware improves.
• Artifact verification: Compare published checksums with locally computed digests after download.
• API and logging: Fingerprint payloads for idempotency keys or non-reversible correlation.
• Change detection: Store a digest of configuration to alert when files drift.
• Blockchain and ledgers: Chains link blocks using hash pointers; this tool only demonstrates the primitive locally.

Hashing is a strictly sequential operation over every byte of the input, so the only honest ways to make it faster are to read the file once instead of once per algorithm, to use the hardware acceleration the device already has where it exists, and to run the algorithms that cannot use it side by side rather than one after another. This tool does all three.

• One pass over the file: selecting four algorithms reads the file once, not four times. Adding an algorithm costs almost nothing extra in reading.
• Hardware acceleration where it exists: the SHA-1 and SHA-2 family run through your device's accelerated implementation, which is several times faster than doing the same work in software.
• Parallel work for the rest: MD5, SHA-3 and CRC-32 have no accelerated path anywhere, so they run alongside each other alongside one another rather than one after another. The wait is the slowest algorithm, not the sum of all of them.
• Streaming, not loading: a file is read a piece at a time, so a multi-gigabyte disc image never has to fit in memory and the page stays responsive throughout.
• A cancel that actually stops: pressing Cancel ends the work immediately rather than setting a flag that nothing checks.

In practice, the four default algorithms over a 100 MB file finish in about half a second on a modern desktop, and the longest single moment the page spends busy during that run is around three milliseconds — which is why typing in the text box never stutters, however much you paste into it.

Everything that decides whether the answer is CORRECT is free. Pro buys scale, which is the part that costs your device real time.

Free

• All eight algorithms, with no restriction on which ones you can select.
• Text of any length up to 5 MB, and one file at a time up to 250 MB.
• HMAC keys in UTF-8, hex or Base64.
• Lowercase hex, uppercase hex and Base64 output.
• Checksum verification with automatic algorithm detection.
• Copy any digest, and download the results of a single run.

Pro

• Queue up to 100 files in one run.
• No imposed size cap — the ceiling is what your device can handle.
• Export a coreutils-format checksum file that sha256sum -c reads directly.
• Export a CSV manifest with one row per file and one column per algorithm.
• Download the whole batch as a single archive.

• MD5 Hash Generator
• SHA-256 Hash Generator
• SHA-1 Hash Generator
• Base64 Encoder/Decoder
• URL Encoder/Decoder
• UUID Generator
• File Metadata Viewer
• All converters