Hash Generator & JWT Tool
Hashing, encoding, and token inspection are tasks that come up constantly in security work, API development, and debugging. This tool handles all of them in one place, entirely in your browser.
Hash Generator & JWT Tool
Hashing, encoding, and token inspection — all client-side.
What this tool covers
The SHA and MD5 functions used here are ones you'd normally reach for a terminal command or a quick Python script. The tool brings them into the browser with zero setup, and because hashing and encoding are entirely stateless operations, there's no reason any of this needs to touch a server.
The SHA-1, SHA-256, SHA-384, and SHA-512 implementations use the browser's built-in SubtleCrypto API — the same cryptographic primitives your OS uses. MD5 uses a well-tested pure-JS implementation since SubtleCrypto deliberately omits it (MD5 is cryptographically weak, but still used widely for checksums and legacy systems).
MD5
32-char hex digest. Still used for file checksums and legacy APIs.
SHA-1
40-char hex digest. Deprecated for security but common in Git object IDs.
SHA-256
64-char hex digest. The current standard for most security work.
SHA-512
128-char hex digest. Higher security margin for sensitive applications.
Base64
Encode/decode binary data for transmission in text protocols.
URL Encode/Decode
Percent-encode and decode query strings and URI components.
HTML Encode/Decode
Escape and unescape HTML entities like &, <, >.
HMAC-SHA256
Message authentication code using a secret key.
JWT
Decode, inspect, and generate JSON Web Tokens.
What is hashing and why does it matter?
A cryptographic hash function takes an input of any length — a single character, a paragraph, or an entire software release — and produces a fixed-size output called a digest or hash. Two properties define whether a hash function is useful in practice: it must be one-way (you cannot reverse the digest back to the original input) and deterministic (the same input always produces the exact same output). A third important property is collision resistance — two different inputs should not produce the same digest, and finding any two inputs that do should be computationally infeasible.
These properties make hashing useful for a wide range of tasks that do not require recovering the original data. If you download a file and compute its SHA-256 hash, then compare that hash against the one published by the software vendor, you can be confident the file was not tampered with in transit. If the hashes match, the file is intact. If they differ — even by a single flipped bit — the digests will be completely different, flagging the corruption or tampering immediately.
Hashing is also central to how deduplication works in storage systems and distributed databases. Rather than comparing gigabytes of content byte-by-byte, a system can compare short hash fingerprints. If two files share the same hash (and the algorithm is collision-resistant), they are almost certainly identical, and the system can avoid storing duplicates.
In digital signatures, hashing plays a supporting role. Signing an entire multi-megabyte document directly with an asymmetric key is slow; instead, the document is hashed first to produce a short digest, and the signature is computed over the digest. Anyone verifying the signature re-hashes the document and checks that the signature matches — this is far faster and just as secure.
Hashing vs. encryption — an important distinction
Hashing is a one-way operation: once you hash data, there is no mathematical way to get the original data back from the digest alone. Encryption is two-way: data is transformed with a key, and the original data can be recovered by decrypting with the correct key. Use hashing when you need to verify or fingerprint data without storing it. Use encryption when you need to recover the original value later.
MD5, SHA-1, SHA-256, and SHA-512 explained
Not all hash algorithms are created equal, and choosing the right one depends on your use case. Here is an honest look at each algorithm this tool supports.
MD5 — fast, widely supported, cryptographically broken
MD5 was designed in 1991 and was once the standard for integrity verification. It produces a 128-bit (32 hex character) digest and runs extremely fast. The problem is that researchers demonstrated practical collision attacks against MD5 in 2004, meaning two different inputs can be crafted to produce the same MD5 hash. This makes MD5 unsuitable for any security-critical purpose.
That said, MD5 remains common in non-security contexts: many content delivery networks use MD5-based ETags to detect cache invalidation, legacy databases store MD5 fingerprints for deduplication, and countless APIs use MD5 for request signing in internal systems where collision attacks are not a practical concern. If the system you are working with already uses MD5 and the data is not security-sensitive, using it is pragmatic. Just do not rely on it to protect anything.
SHA-1 — deprecated for security, still alive in version control
SHA-1 produces a 160-bit (40 hex character) digest. Like MD5, collision attacks against SHA-1 have been demonstrated — Google's SHAttered project in 2017 produced two different PDF files with the same SHA-1 hash. Certificate authorities stopped issuing SHA-1 TLS certificates after 2016, and browsers now reject them.
Where SHA-1 lives on is in Git: every commit, tree, blob, and tag in a Git repository is identified by its SHA-1 hash. Git is aware of SHA-1's weaknesses and has been adding SHA-256 support, but the vast majority of existing repositories still use SHA-1 object IDs. For this reason, being able to compute SHA-1 hashes quickly remains useful for anyone debugging Git internals or writing tooling around the Git object model.
SHA-256 — the current workhorse of security
SHA-256 is part of the SHA-2 family and produces a 256-bit (64 hex character) digest. No practical collision attacks exist against SHA-256, and it is the default choice for most modern security applications: TLS certificates, code signing, JWT signatures using HS256, Bitcoin's proof-of-work algorithm, package managers like npm and pip for dependency integrity, and container image layer verification in Docker all rely on SHA-256.
When in doubt, SHA-256 is the right choice. It is fast enough for interactive use, supported natively in every modern browser and runtime, and provides a security margin that no currently known attack can overcome.
SHA-512 — larger output, higher margin
SHA-512 produces a 512-bit (128 hex character) digest. On 64-bit hardware, SHA-512 is actually faster than SHA-256 for long messages because the underlying rounds process more data per operation. It is used in applications that need an extra security margin, or where the larger output size is beneficial — for example, deriving longer cryptographic keys, or in systems where the digest itself serves as key material. For everyday hashing tasks, SHA-256 and SHA-512 are similarly secure in practice; the choice is usually dictated by what the receiving system expects.
When to use which algorithm
| Algorithm | Output | Use case |
|---|---|---|
| MD5 | 32 hex | File checksums, non-security ETags |
| SHA-1 | 40 hex | Git object IDs, legacy HMAC |
| SHA-256 | 64 hex | API signatures, JWT HS256, TLS |
| SHA-512 | 128 hex | High-security hashing, key derivation |
HMAC — keyed hashing for message authentication
A plain hash tells you whether data was corrupted, but it does not tell you who produced it. Anyone can compute the SHA-256 of a message. HMAC (Hash-based Message Authentication Code) solves this by mixing a secret key into the hashing process. The result is a digest that can only be reproduced by someone who knows the key.
HMAC-SHA256 is the most common variant and is used extensively in API authentication. AWS Signature Version 4, Stripe webhook verification, GitHub webhook signatures, Twilio request validation, and the HS256 JWT signing algorithm all use HMAC-SHA256. The sender computes an HMAC over the request body (or the canonical request string) using a shared secret, and the receiver independently computes the same HMAC and compares. If they match, the message is authentic and unmodified.
This tool computes HMAC-SHA256 using the browser's SubtleCrypto API, which calls the operating system's native cryptographic library under the hood. The output can be returned as a hex string or as Base64, depending on what the target API expects. AWS uses Base64, most custom webhook systems use hex — always check your API documentation.
HMAC is not the same as a password hash
HMAC is designed for speed, which is what you want when authenticating millions of API requests per second. Precisely because it is fast, HMAC (including HMAC-SHA256) is the wrong choice for hashing user passwords. Password hashing requires functions that are intentionally slow — bcrypt, Argon2, or scrypt — so that brute-force attacks remain computationally infeasible even if the database is compromised.
Real-world use cases for hashing
File integrity and checksums
When you download software, operating system images, or large archives, the provider typically publishes a SHA-256 checksum alongside the download. After downloading, you compute the hash of the file locally and compare it against the published value. If they match, the file arrived intact and was not modified in transit or on the server. This protects against accidental corruption (network errors, storage failures) and — if the checksum page itself is served over HTTPS — against some forms of supply-chain tampering.
Package managers like npm, pip, and Cargo use this principle automatically: every package is accompanied by a hash of its content, and the package manager verifies the hash before installation. This is why you see entries like integrity: sha512-abc123... in your package-lock.json.
Content deduplication
Storage systems that need to avoid storing duplicate data compute a hash of each chunk or file and store the hash as a key. Before writing a new piece of data, the system checks whether that hash already exists in its index. If it does, the system simply records a reference to the existing copy rather than writing again. This is how cloud backup services, container image registries, and version control systems like Git achieve space-efficient storage. Git stores every file version as a blob object whose name is the SHA-1 hash of its content — identical file content across branches or commits is automatically deduplicated at the storage level.
Digital signatures and code signing
Asymmetric digital signatures work by hashing the data to be signed, then encrypting the hash with a private key. The resulting signature is distributed alongside the data. A verifier decrypts the signature with the corresponding public key to recover the hash, independently hashes the data, and checks that the two match. Because only the holder of the private key could have produced a valid signature over that exact hash, this authenticates both the identity of the signer and the integrity of the data. Operating system updates, app store packages, browser extensions, and software release artifacts are all routinely signed this way.
Password storage — what not to do, and why
A common early mistake in web development is to store passwords as plain SHA-256 (or worse, MD5) hashes. The logic seems sound: the hash is one-way, so even if the database leaks, the attacker can't get the passwords back. The problem is that attackers don't need to reverse the hash — they can hash billions of candidate passwords and compare. Modern GPUs can compute over 10 billion SHA-256 hashes per second. An 8-character password from a typical set of characters can be cracked in minutes.
Salting partially addresses this: a unique random value (the salt) is generated for each user and concatenated with their password before hashing. The salt is stored in plaintext alongside the hash. This prevents precomputed rainbow table attacks and means attackers must crack each password individually rather than all at once. However, even salted SHA-256 is still vulnerable to brute-force because SHA-256 is too fast.
The correct approach is to use a password-hashing function designed for exactly this problem: bcrypt, Argon2, or scrypt. These functions are tunable — you can configure how slow they are (the "cost factor" or "work factor") — and they include salting automatically. As hardware gets faster, you increase the cost factor to keep pace. This tool is useful for computing fast hashes (file checksums, API signatures), but if you are building a user authentication system, please use a dedicated password hashing library.
Hashing in detail
Paste or type your input text, select the algorithm from the dropdown, and the hash appears immediately — no button press needed. All four algorithms run in parallel so switching between them is instant.
For most text inputs, the tool encodes the string as UTF-8 bytes before hashing, which matches the behavior of command-line tools like sha256sum and openssl dgst. This means if you hash the string "hello" here, you will get the same result as running echo -n "hello" | sha256sum in a terminal (note the -n flag, which suppresses the trailing newline that echo adds by default).
When to use which algorithm
| Algorithm | Output | Use case |
|---|---|---|
| MD5 | 32 hex | File checksums, non-security ETags |
| SHA-1 | 40 hex | Git object IDs, legacy HMAC |
| SHA-256 | 64 hex | API signatures, JWT HS256, TLS |
| SHA-512 | 128 hex | High-security hashing, key derivation |
JWT decoder & generator
JWTs are Base64URL-encoded JSON, which makes them opaque until you decode them. The JWT tab does this instantly — paste any token and you'll see the header algorithm, all payload claims, and whether the token is expired based on the exp claim.
A JWT consists of three Base64URL-encoded parts separated by dots: a header describing the signing algorithm, a payload containing the claims (arbitrary JSON data), and a signature computed over the first two parts. The header and payload are not encrypted — they are merely encoded — so anyone who receives a JWT can read its contents without knowing the secret. The signature ensures that the token was issued by someone who knew the secret and that the contents have not been tampered with since.
This has a practical implication: do not put genuinely sensitive data in a JWT payload unless the token itself is transmitted over an encrypted channel (HTTPS) and you understand that anyone who intercepts the raw token string can read the payload. Standard claims like user IDs, roles, and expiry times are fine. Putting unencrypted credit card numbers or passwords in a JWT payload is not.
Decode a JWT
- 1.Paste your JWT (starts with eyJ…)
- 2.Header, payload, and signature display immediately
- 3.Expiry status shows as valid or expired
- 4.Note: signature verification requires the secret key
Generate a JWT
- 1.Enter your payload as JSON
- 2.Set algorithm (HS256, HS384, HS512)
- 3.Enter your secret key
- 4.Copy the signed token for use in your app
Base64, URL encoding, and HTML encoding
Not every encoding in this tool is about cryptography. Base64, URL encoding, and HTML entity encoding solve a different problem: representing arbitrary data safely within a constrained text context.
Base64 encodes arbitrary binary data as a string using 64 printable ASCII characters (A-Z, a-z, 0-9, +, /). It increases the size of the data by about 33% but makes it safe to transmit through systems that only handle text. Email attachments, inline images in HTML (data URIs), and many API protocols that carry binary payloads in JSON fields all use Base64. The URL-safe variant replaces + with - and / with _ to avoid characters that have special meaning in URLs.
URL encoding (percent-encoding) converts characters that are not allowed or have special meaning in URLs — spaces, ampersands, equals signs, quotation marks — into a % followed by their two-digit hexadecimal byte value. A space becomes %20, an ampersand becomes %26. This is essential when constructing query strings that contain user input, API keys with special characters, or any data that might conflict with URL syntax.
HTML entity encoding escapes characters that have special meaning in HTML markup. The less-than sign becomes <, the ampersand becomes &, and so on. This is a fundamental defense against cross-site scripting (XSS) attacks: by encoding user-supplied content before inserting it into HTML, you prevent it from being interpreted as markup. Modern frameworks handle this automatically, but understanding the encoding is useful when debugging escaped content or working with raw template engines.
Privacy and local execution
All operations in this tool — hashing, HMAC signing, JWT encoding and decoding, Base64, URL encoding, and HTML encoding — execute entirely in your browser. No input text, no secret keys, no hash outputs, and no JWT payloads leave your machine. The page makes no network requests after it has loaded.
The SHA-family algorithms use the browser's SubtleCrypto API, which is part of the Web Crypto standard and is implemented natively by every modern browser. MD5 runs through a well-audited pure-JavaScript implementation because the Web Crypto standard intentionally excludes MD5 (its designers considered it too weak to standardize). Being honest about this: the pure-JS MD5 path is not using hardware-accelerated crypto, but for the use cases where MD5 is still appropriate (non-security checksums, legacy integrations), this is perfectly adequate.
If you are working with genuinely confidential data — production API keys, private keys, personal health information — running hashing locally in the browser is safer than using an online tool that sends your input to a server. Even so, for high-stakes production security tasks, using native command-line tools or server-side libraries in your own infrastructure is the most conservative option.
Pro tips
- →For HMAC-SHA256, the output format (hex vs Base64) matters — AWS uses Base64, most custom APIs use hex. Check your API docs before choosing.
- →When verifying a file checksum, paste the file content as text or use the 'hash file' mode to hash binary data via the FileReader API.
- →Base64 padding characters (=) are sometimes stripped in URL contexts — the URL-safe Base64 option handles this automatically.
- →JWT exp claims are Unix timestamps in seconds, not milliseconds — the decoder converts this to a readable date automatically.
- →To verify an HMAC from a webhook provider, compute the HMAC over the exact raw request body bytes — even a single added whitespace character will produce a completely different digest.
- →If you need to compare two hashes for equality, use a constant-time comparison in your server code rather than a regular string equality check. Timing side-channels can leak information about how many characters match.
Frequently Asked Questions
Are my hashes or secrets uploaded anywhere?
No. SHA-1, SHA-256, SHA-384, and SHA-512 use the browser's SubtleCrypto API, and MD5 uses a pure-JS implementation since Web Crypto has no MD5. Everything is computed locally — nothing leaves your browser.
Can I decode a JWT to see its payload?
Yes. Paste any JWT into the JWT tab. The tool splits the header, payload, and signature, Base64-decodes each part, and displays the JSON claims. It also shows expiry status based on the exp claim.
How does HMAC-SHA256 work in this tool?
Enter your message and a secret key. The tool uses SubtleCrypto's importKey and sign methods to produce the HMAC-SHA256 digest, returned as a hex string or Base64.
Is it safe to store passwords as plain SHA-256 hashes?
No. Fast hash functions like SHA-256 are not suitable for password storage. Without a salt, they are vulnerable to rainbow table attacks. Even salted, they are too fast — modern GPUs can test billions of candidates per second. Use bcrypt, Argon2, or scrypt for passwords.
What is the difference between hashing and encryption?
Hashing is one-way: you cannot recover the original data from a hash. Encryption is two-way: data can be decrypted back to plaintext with the correct key. Use hashing for integrity verification and fingerprinting; use encryption when you need to recover the original value.
Related Articles & Guides
Hash Generator Guide: MD5, SHA-1, SHA-256 Explained
Cryptographic hash functions are one of the foundational building blocks of modern digital security. They're…
Read guide →ArticleHash Generator & JWT Tool: MD5, SHA-256, Base64, HMAC & JWT Online
Generate MD5, SHA-1, SHA-256, SHA-512 hashes, encode Base64, sign HMAC, and decode JWTs.
Read guide →BlogWhat Is JSON? Complete Guide to JSON Formatting
JSON — JavaScript Object Notation — is the lingua franca of modern web development. Open any REST API…
Read guide →