NiftyWebTools Start free

Nifty Tools

hash generator

Free hash generator in your browser. SHA-256, SHA-384, SHA-512, SHA-1 legacy. Text or files up to 100 MB. Hex or Base64. No upload, no signup.

Processing mode: Local Browser-local

Pick input mode, algorithm, and format, then click Hash.

Keep working

Related tools

UUID Generator — Free, In Your Browser Free uuid generator in your browser. v4 and v7, bulk up to 1000, hyphenated/braces/uppercase formats, RFC 4122 + RFC 9562. No upload, no signup. JWT Decoder — Free, In Your Browser Use a free jwt decoder in your browser to read JWT header and payload. Base64URL decode, exp and iat highlighted, browser-local. No signature verification. Base64 Encoder — Free, In Your Browser Use a free base64 encoder in your browser. Encode text, files, and data URIs locally. UTF-8 safe, URL-safe output. No upload, no signup.

How to use it

Hash Generator — SHA-256, SHA-512, In Your Browser

  1. Pick the input mode (text or file), choose the algorithm (SHA-256 by default; SHA-384, SHA-512, or legacy SHA-1 are alternatives), and select hex or Base64 output.
  2. Click Hash. The page calls `crypto.subtle.digest(algorithm, bytes)` on either a `TextEncoder`-encoded `Uint8Array` (text mode) or the file's `ArrayBuffer` (file mode), then formats the resulting bytes as hex (lower or upper case) or Base64.
  3. Copy the digest, download it as `.txt`, or read it off the screen. The whole pipeline runs in your browser — `crypto.subtle.digest()` runs in the same engine that handles TLS handshakes.

Good for

Common use cases

People reach for a hash generator when they need a deterministic, fixed-length fingerprint of some content — a value that is the same every time the input is the same, and (for any modern algorithm) effectively unguessable for any specific target output. The classic shapes are: verifying that a file you downloaded matches the SHA-256 the publisher posted next to the link (Linux distribution ISOs, Bitcoin Core releases, Ledger firmware, npm package tarballs, Homebrew bottles); generating a content-addressable identifier that will be the same on every machine that sees the same bytes (Git uses SHA-1 for commit and blob hashes, IPFS uses SHA-256 for CIDs, Docker uses SHA-256 for image and layer digests); building a deduplication key for a storage layer that should treat byte-identical inputs as the same blob; or feeding a known-input known-output value into a higher-level construct like an HMAC, a Merkle tree, a signed JWT, or a proof-of-work scheme. What a hash generator is *not* for is encrypting data (a hash is one-way — there is no inverse operation that recovers the input from the output), securing a file against being read (a hash is a fingerprint, not a lock), or proving authenticity on its own — a hash that travels alongside the file it describes proves nothing if an attacker can replace both. The constructions that *do* prove authenticity are HMAC (a hash plus a secret key both ends share) and digital signatures (a hash plus an asymmetric key pair); both are strictly richer than a bare hash and live on dedicated tool pages. The right algorithm for new work in 2026 is SHA-256 or SHA-512, both members of the SHA-2 family; SHA-1 is included on this page only as a legacy option for compatibility with systems that still emit SHA-1 fingerprints (Git, deprecated TLS certificate fingerprints, some older Amazon S3 ETags, legacy Subversion checksums), not as a security recommendation. MD5 is intentionally absent — see the FAQ.

Processing mode

Browser-local

Files are processed by your browser. They never reach our servers.

Questions

Hash Generator — SHA-256, SHA-512, In Your Browser FAQ

What's the difference between hashing, encryption, HMAC, and a digital signature — when do I want each?

A hash takes input bytes and emits a fixed-length, deterministic fingerprint with no key involved. Anyone can compute the same hash over the same input and reach the same answer; that is exactly what makes it useful for integrity checks and content-addressable identifiers, and exactly why it does not, on its own, prove who produced the bytes. Encryption is two-way: it transforms input into ciphertext using a key, and the ciphertext can be decrypted back to the original input. HMAC is "keyed hashing" — it combines a hash function (e.g. SHA-256) with a shared secret key, producing a tag that anyone with the key can verify but no one without it can forge; it proves authenticity *between two parties who share a key*. A digital signature uses asymmetric cryptography (RSA, ECDSA, Ed25519) so the signer holds a private key and verifiers hold the corresponding public key — it proves authenticity *to anyone who has the public key* and is non-repudiable. Concrete mapping: file integrity check → hash; API request authentication where both sides hold a secret → HMAC; software release that anyone in the world should be able to verify → signature; storing a value that should be readable later → encryption. This page generates raw hashes only; HMACs and signatures live elsewhere because they require key material the page would have to handle.

Why does this tool not generate MD5 hashes?

Two reasons, one technical and one positional. The technical reason is that the Web Crypto specification — the API that this page uses, `crypto.subtle.digest()` — explicitly does not include MD5 in the algorithm list it requires browsers to implement. The supported algorithms are SHA-1, SHA-256, SHA-384, and SHA-512; MD5 is absent from every major browser's Web Crypto implementation as a result. Implementing MD5 in pure JavaScript inside the page would be possible but would mean shipping a hand-rolled cryptographic primitive on a page whose entire pitch is "uses the browser's native crypto path" — a contradiction that would also slow the page down and add an attack surface no audit could realistically clear. The positional reason is that MD5 is cryptographically broken — practical collisions have been published since 2004 and chosen-prefix collisions since 2007 — so the use cases for it are narrow and legacy: comparing CD-image checksums published before 2010, working with old Subversion repository hashes, or matching vendor-supplied MD5s that pre-date a modernization push. If the legacy use is real and Search Console traffic shows organic demand for "md5 generator", a separate dedicated page is the right shape, with copy that explicitly frames MD5 as a corruption-detection checksum rather than a security primitive. This page does not pretend MD5 is an option for new work.

Is SHA-1 still safe to use?

Not for any new security purpose. SHA-1 has had practical collision attacks since 2017 (the SHAttered paper demonstrated two distinct PDFs with the same SHA-1) and chosen-prefix collisions are within reach for well-resourced attackers; major web browsers stopped accepting SHA-1 in TLS certificates in 2017, and TLS 1.3 disallows SHA-1 outright in handshakes. SHA-1 is included on this page only because real systems that produce SHA-1 fingerprints today still need to be interoperated with: Git's commit and blob hashes are SHA-1 in the vast majority of repositories (the SHA-256 transition is standardized but not yet default), legacy Subversion repositories use SHA-1, some older AWS S3 ETags use SHA-1 of the object body, and a handful of internal-systems integrations still emit SHA-1 fingerprints because that is what they were built to emit a decade ago. Using the SHA-1 button to compute a hash that you will compare against an existing SHA-1 is fine. Using SHA-1 because you are designing a new authentication scheme, a new content-addressable scheme, or a new signature scheme is not.

Can I hash a file by drag-and-drop, and is the file actually uploaded?

The file path uses a standard `<input type="file">` plus a click — drag-and-drop into the file input is a browser feature that works wherever the input is visible, no extra page wiring required. The file is read into an `ArrayBuffer` in the page's own JavaScript context using `Blob.arrayBuffer()`, then passed to `crypto.subtle.digest()`. There is no `fetch()` call, no `XMLHttpRequest`, no WebSocket, no `<form action="…">` — the page makes no network request after the initial page load. Open your browser's developer tools, switch to the Network tab, hash a file, and you will see no requests fire. The 100 MB cap exists because the entire file goes into memory at once (Web Crypto's `digest()` does not have a streaming variant in the browser as of 2026 — the `crypto.subtle.digest()` interface accepts a `BufferSource`, not a stream); on a phone or a low-RAM laptop, holding two or three multi-GB ArrayBuffers in JavaScript heap can cause the tab to crash. The cap is conservative for that reason.

Why does my SHA-256 hash here differ from `sha256sum` on Linux for the same string?

Almost always because of trailing newlines or trailing whitespace. `sha256sum` and the GNU coreutils family hash the literal byte stream they receive, including the trailing `\n` that `echo` adds by default; this page hashes exactly the bytes in the textarea, with no automatic newline. `echo "hello" | sha256sum` hashes six bytes (`h`, `e`, `l`, `l`, `o`, `\n`) and produces a different hash than `printf '%s' "hello" | sha256sum` (five bytes). Pasting `hello` into this page and hashing it matches the `printf` variant, not the `echo` variant. Other common causes are character-encoding differences (Windows tools sometimes default to UTF-16 LE on the clipboard while this page always encodes UTF-8 via `TextEncoder`), CRLF vs LF line endings inside multi-line input, or invisible Unicode characters like a BOM (`\uFEFF`) at the start of a copied string. When two implementations disagree on a hash, the bytes they are hashing disagree — the algorithm itself is fully deterministic.

Are my files or text uploaded anywhere?

No. `crypto.subtle.digest()`, `TextEncoder`, and `Blob.arrayBuffer()` are native browser APIs that run inside this tab. The text you paste, the file you select, the resulting digest, the copy-to-clipboard, and the `.txt` download all stay on your device. There is no signup, no watermark, no analytics on the content of the input or the output. The page is safe for hashing files whose contents you treat as sensitive — internal release artifacts, backup archives, secrets you are about to commit-encrypt, anything where having the bytes leave your machine would be a problem on its own.

Will this tool stay free?

The basic workflow is designed to stay free. Paid upgrades later will focus on bigger limits, batch work, OCR, saved presets, and ad-free use.