Security
Every Security tool on Toolz.dev: 4 free utilities that run entirely in your browser. No signup, no uploads, no downloads.
Four tools sit here and each one has a boundary that is easy to cross by accident. A hash generator produces a fingerprint that cannot be turned back into the input, which is not the same as encrypting it. A JWT decoder reads a token without checking whether it is genuine. A password generator makes a string no human would choose, and a strength checker estimates how long one would survive a guessing attack.
The reason all four run client-side is not a feature list item here. The inputs to these tools are the exact things you should never paste into a remote service: a production token, a password you are about to use, a file you are checksumming because you do not trust its source. Everything on this page is computed in your browser, with no request carrying the value anywhere.
What each security tool does, and what it does not
| Tool | What it does | What it does not do |
|---|---|---|
| Hash Generator | MD5, SHA-1, SHA-256, SHA-384, SHA-512 digests | Encrypt anything, or hash passwords safely |
| JWT Decoder | Reads the header, payload and claims, checks expiry | Verify the signature, which needs the secret |
| Password Generator | Random strings from a character set you choose | Store or remember them for you |
| Password Strength Checker | Entropy estimate with penalties for patterns | Tell you a password is safe from a leak |
Hashing is not encryption
A hash is one-way by design: it maps any input to a fixed-length digest, and there is no key and no procedure that recovers the input. That is what makes it right for checking a download against a published checksum, for detecting whether two files differ, and for deduplicating content. It is also what makes the phrase decrypt this hash meaningless. What a cracking service really does is guess inputs, hash each one and compare, which works quickly on short or common inputs and not at all on long random ones.
The algorithm matters. MD5 and SHA-1 are both broken for collision resistance, meaning two different inputs can be constructed to produce the same digest, and both have practical demonstrations behind them: SHA-1 since 2017. Neither should be used where an attacker chooses the input, though both remain fine for an accidental-corruption checksum. SHA-256 is the sensible default, and the hash generator computes it through the Web Crypto API rather than a hand-rolled implementation.
The one place none of these belong is a password database. A general-purpose hash is fast, which is exactly wrong when the attacker is guessing billions of candidates, and unsalted digests fall to a lookup table immediately. Passwords want a deliberately slow, salted, memory-hard function such as bcrypt, scrypt or Argon2.
A JWT is signed, not secret
The payload of a JSON Web Token is base64url-encoded, not encrypted. Anyone holding the token can read every claim in it, which surprises people who have put an email address, a role or an internal user id in there and treated the encoding as a wrapper. The signature protects integrity: it proves the token was issued by whoever holds the key and has not been altered since. It does not hide anything.
That is why the JWT decoder is explicitly decode-only. Verifying a signature requires the secret or public key, and a browser tool that asked for your signing secret would be asking for the one value that must never leave your server. What it does check is the part that needs no key: the structure, the algorithm named in the header, and the timing claims - exp, nbf and iat - which is where most debugging ends up anyway, because a token that stopped working usually just expired or arrived at a server whose clock has drifted.
What actually makes a password strong
Length beats complexity, and it is not close. Each additional character multiplies the search space by the size of the alphabet, while adding a symbol to a short password multiplies it once. This is why the old advice to substitute a for @ and add an exclamation mark aged so badly: attackers apply exactly those substitutions as rules, so P@ssw0rd! is barely harder to guess than password. Modern guidance, including NIST SP 800-63B, drops mandatory composition rules and mandatory rotation, and asks instead for length and a check against known-breached values.
The strength checker reflects that: it computes entropy from the character set and length, then applies penalties for the patterns that make a password more guessable than its raw arithmetic suggests, such as dictionary words, keyboard runs and dates. The honest limit is that no local checker knows whether your password appeared in a breach corpus, and a password that has been leaked is worthless regardless of its entropy. The password generator sidesteps the whole question by drawing from the Web Crypto API, so the result has no pattern to penalise.
Frequently asked questions
- Can a hash be reversed or decrypted?
- No. Hashing is one-way by construction: there is no key and no algorithm that recovers the input from the digest. Services that appear to reverse a hash are guessing inputs, hashing each one and comparing, which works on short or common values and fails entirely on long random ones.
- Is MD5 still safe to use?
- Not where an attacker can choose the input. MD5 and SHA-1 are both broken for collision resistance, meaning two different inputs can be constructed to share a digest, so neither belongs in a signature or an integrity check against a hostile party. Both remain fine for detecting accidental corruption. Use SHA-256 as the default.
- Does decoding a JWT verify that it is valid?
- No. Decoding reads the base64url payload, which anyone holding the token can do; verifying checks the signature against the issuer secret or public key, which a browser tool cannot do without that key. This decoder checks structure, algorithm and the expiry claims, and leaves signature verification to your server.
- Is it safe to paste a token or password into this site?
- These tools compute in your browser and send nothing anywhere, so the value never leaves your device. That is the exception rather than the rule: most online decoders and hash tools post the input to a server, which means pasting a production token into one has disclosed it. Read a tool description before pasting a live secret into any site, including this one.
- Can I use SHA-256 to store passwords?
- No. General-purpose hashes are built to be fast, which is the opposite of what password storage needs when an attacker is testing billions of guesses per second. Use a deliberately slow, salted, memory-hard function: bcrypt, scrypt or Argon2, which is the current recommendation.
- What makes a password strong?
- Length, above everything else. Each extra character multiplies the search space, while a symbol added to a short password multiplies it once, and predictable substitutions such as a for @ are the first rules a cracking tool applies. NIST guidance now favours long passphrases and screening against breached password lists over composition rules and forced rotation.