Hash Generator: Practical Tips and Common Mistakes
Reviewed by the OnlineFree.app team · Updated
Key points
- The Hash Generator computes MD5, SHA-1, SHA-256, SHA-384 and SHA-512 entirely in your browser, so input text is never uploaded.
- SHA-256 output is 32 bytes: 64 lowercase hex characters or 44 Base64 characters for the same digest.
- Base64 in the tool encodes the raw digest bytes, not the hex string, so never re-encode the hex yourself.
- HMAC mode reuses the same output fields and turns a plain digest into a keyed signature for webhooks and API authentication.
- A trailing newline or space changes the digest completely; check the byte counter before assuming the algorithm is wrong.
What does the Hash Generator produce?
The Hash Generator turns any text into a fixed-length cryptographic digest using MD5, SHA-1, SHA-256, SHA-384 or SHA-512, and shows that digest twice: as lowercase hexadecimal and as Base64. Results refresh on every keystroke, there is no submit button, and the string you type never leaves the browser tab.
Output length depends only on the algorithm, never on how much you type. MD5 returns 32 hex characters (16 bytes), SHA-1 returns 40 (20 bytes), SHA-256 returns 64 (32 bytes), SHA-384 returns 96 (48 bytes) and SHA-512 returns 128 (64 bytes). With SHA-256 selected, "hello world" always produces b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9.
One implementation detail is worth knowing: input is encoded as UTF-8 without a BOM before hashing, which keeps results identical to Node's crypto module and to openssl for accented or multi-byte text as well as plain ASCII. The status line reports the exact byte count, for example "Hashing 24 bytes as SHA-256", which is the quickest way to spot a stray newline or a character you did not expect.
Legacy algorithms: when MD5 and SHA-1 are fine
Both MD5 and SHA-1 carry a legacy label in the tool for a reason: they are no longer collision-resistant, so two different inputs can be crafted to produce the same digest. RFC 6151 is the standard summary of those attacks and states plainly that MD5 and SHA-1 must not be used where collision resistance is required.
That does not make them useless. For non-adversarial checksums — deduplicating records, building cache keys, matching a legacy API that expects an MD5 of a request body — they still work and are still widely required. The problem appears only when an attacker can influence both the input and the comparison.
Our default advice is to keep SHA-256 selected unless a specification says otherwise, and to treat MD5 or SHA-1 output as an integrity check rather than a security control. If a documented test vector lists an MD5 digest, reproduce it here to confirm your implementation, but do not design new systems around it.
Hex or Base64: which digest should you copy?
Both rows describe exactly the same digest bytes, so neither is more correct. Hex is easier to compare character by character when you are reading a test failure; Base64 is roughly a third shorter, which matters when a hash has to sit inside a header, a token or a URL. SHA-256 is 64 hex characters, or 44 Base64 characters ending in "=".
The mistake we see most often is double-encoding. The Base64 field encodes the raw 32 digest bytes, not the 64-character hex string. Base64-encoding the hex yourself produces a much longer value — 88 characters for SHA-256 — that no server will ever match. Copy the Base64 row instead of converting the hex row.
Case and whitespace cause quieter failures. Hex is emitted in lowercase with no spaces, while some specifications expect uppercase, so a case-sensitive comparison can fail even though the digest is identical. Normalise case after copying, and never insert line breaks into a digest you intend to paste back into code.
HMAC keys: signing, not just hashing
An HMAC is a hash mixed with a secret key. Because the key participates in the calculation, someone who can modify a message cannot recompute its digest without also holding the key — which is why HMAC-SHA256 is the usual choice for webhook signatures and API request authentication. Open the Add HMAC key row and the same two output fields switch to HMAC-<algorithm>; leave the key empty for a plain digest.
RFC 4231 publishes official HMAC-SHA-2 test vectors, and the printable-ASCII cases are easy to reproduce here. Test case 2 uses the key Jefe and the message "what do ya want for nothing?", which yields 5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843. Matching a documented vector confirms that you and your server agree on key and message bytes before you debug anything else.
Two practical notes. Do not build your own scheme by hashing key + message: that pattern is vulnerable to length-extension attacks on SHA-1 and SHA-2, the exact problem HMAC was designed to avoid. And HMAC output length follows the algorithm, not the key, so HMAC-SHA-256 is always 32 bytes whether your key is 8 characters or 200.
Common hashing mistakes we keep seeing in tests
One extra character changes everything. When you copy a string from a terminal, a CSV cell or a chat message, you may carry a trailing newline or space with it, and the digest will look entirely unrelated — that is the avalanche effect working as intended. "hello world" and "hello world " share no visible output.
Empty input is not an error: it returns the valid digest of zero bytes, e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 for SHA-256. A populated result field therefore tells you nothing about whether the input was what you meant. Use the byte counter in the status line; "café" is 5 bytes in UTF-8, not 4.
Encoding mismatches are the second big source of apparently wrong hashes. The tool hashes UTF-8 without a BOM, so a file written as UTF-16 by a Windows tool, or text pasted from a page that inserted smart quotes, will not match your server. To validate the shape of an expected digest before comparing, a pattern such as ^[0-9a-f]{64}$ is quick to check in the Regex Tester.
Privacy, accuracy and when to verify elsewhere
The SHA-2 family is computed through the browser's built-in Web Crypto API, and MD5 through a small bundled JavaScript implementation, so every digest is produced locally. Nothing is posted to a server, which is the main reason the tool works this way: the strings people hash while debugging are often internal payloads, tokens or signing keys.
Local computation does not make any web page a safe place for production secrets, and that is our honest limitation. If a string must stay secret, hash it on the machine that already holds it — printf 'hello world' | openssl dgst -sha256, or a two-line Node script. Cross-checking an important digest against a second implementation is also the fastest way to catch a typo in a test fixture.
The Hash Generator is part of the free OnlineFree.app collection and shares the same no-upload design as the rest of those tools. As of 2026, MD5 and SHA-1 remain legacy-only for security work, and plain hashes remain the wrong tool for storing passwords — use Argon2id, bcrypt or scrypt with a unique per-user salt instead.
Frequently asked questions
Is the Hash Generator safe for confidential text?
Yes. The Hash Generator computes every digest inside your browser, using the Web Crypto API for SHA-2 and a bundled JavaScript MD5, so input text is never uploaded. We still recommend against pasting production secrets, private keys or HMAC keys into any web page, including this one. If a value is genuinely sensitive, run the same hash locally with openssl or Node.
What is the SHA-256 hash of "hello world"?
The SHA-256 digest of the ASCII string hello world is b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9. The same input gives 5eb63bbbe01eeed093cb22bb8f5acdc3 in MD5 and 2aae6c35c94fcfb415dbe95f408b9ce91ee846ed in SHA-1. Type hello world with no trailing space or newline into the Hash Generator to reproduce these values exactly.
Can the Hash Generator create HMAC-SHA256 digests?
Yes. Open the Add HMAC key row, paste your secret, and the two output fields switch from a plain hash to HMAC-SHA256, HMAC-SHA384 or HMAC-SHA512 depending on the algorithm you selected. Leaving the key empty returns a plain digest. The key is treated as UTF-8 text, so it must match the byte sequence your server uses.
Why does my hash not match the expected value?
The most common causes are an invisible trailing newline or space in the pasted text, a different character encoding, the wrong algorithm, or comparing a hex digest against a Base64 value. The Hash Generator always hashes UTF-8 without a BOM. Check the byte counter in the status line and normalise letter case before comparing.
Should I store passwords with MD5 or SHA-256?
No. Plain MD5, SHA-1 and SHA-256 are fast and unsalted, which makes brute-force and precomputed-table attacks cheap, and MD5 and SHA-1 are also collision-broken. Use a dedicated password hash such as Argon2id, bcrypt or scrypt with a unique random salt per user. The Hash Generator is intended for checksums, cache keys and API signatures.