Security tools online, with the honest part stated up front
Generate passwords, check certificates, inspect headers, sign messages and audit DNS. Some of these can run entirely on your device. Some physically cannot, because they have to ask a remote server a question. This page tells you which is which before you type anything.
Every security tool
Free, no account, and 10 of them ready now, out of 149 across the site.
Exactly what happens to what you type
A security tool asking you to trust it without explaining itself is a contradiction. So here is the breakdown, tool by tool.
| Tool | Where it runs | What is sent, if anything |
|---|---|---|
| Password generator | Local | Nothing. Randomness comes from crypto.getRandomValues in your browser. |
| Password strength tester | Local | Nothing. The password is scored in the page and never transmitted. |
| HMAC generator | Local | Nothing. Message and secret key both stay in memory, via the Web Crypto API. |
| Cookie consent generator | Local | Nothing. Output is assembled from your inputs in the page. |
| GDPR privacy policy generator | Local | Nothing. Company details are only used to fill the template you see. |
| SSL certificate checker | Network | The domain name you enter, so the certificate chain can be fetched and read. |
| DNS lookup | Network | The domain name, sent to a public DNS over HTTPS resolver. |
| HTTP header checker | Network | The URL you enter, so its response headers can be retrieved. |
The pattern is simple. If the answer depends on something only a remote server knows, such as which certificate a domain is presenting today, the domain has to be sent somewhere. If the answer can be computed from what you typed, it is computed here and nothing moves. No tool in the second group ever sends a password, a key or a message body.
Which algorithms are still safe to use
The hash and HMAC tools support older algorithms because people still need to verify legacy output. Supporting one is not a recommendation. Here is where each actually stands.
Practical collisions since 2004, and chosen prefix collisions since 2007. Fine for a non adversarial checksum. Never for signatures, certificates or passwords.
The SHAttered attack produced a real collision in 2017. Retired from TLS certificates. Git still uses it for object naming with added hardening.
The workhorse. No practical attacks. The right default for integrity checks, HMAC and digital signatures.
Same family, larger digest. Often faster than SHA-256 on 64 bit hardware despite the bigger output.
Keccak based, structurally different from SHA-2. Immune to the length extension issue by design.
Fast hashing is the problem, not the solution. Use bcrypt, scrypt or Argon2, which are deliberately slow and salted.
One subtlety worth knowing if you build your own integrity check. SHA-256 is vulnerable to a length extension attack, meaning someone who knows hash(secret + message) and the length of the secret can compute a valid hash for a longer message without knowing the secret. That is precisely the problem HMAC solves, and it is why you should reach for HMAC rather than concatenating a key onto a message yourself.
What a strength score actually measures
Strength is entropy, measured in bits, and entropy is a property of how a password was generated rather than how it looks. A password is not strong because it contains a symbol. It is strong because there were too many equally likely alternatives.
| Password | Entropy | Why |
|---|---|---|
| P@ssw0rd! | About 10 bits | A dictionary word with predictable substitutions. Cracking tools try these first, so the symbols buy almost nothing. |
| Summer2026! | About 16 bits | Season plus year plus punctuation is one of the most common patterns in every breach corpus. |
| xkcd style, 4 words | About 44 bits | Four words drawn randomly from a 7,776 word list. Weak against a targeted attack, fine for many uses. |
| xkcd style, 6 words | About 66 bits | Same method, two more words. Memorable and genuinely strong. |
| 16 random characters | About 95 bits | Generated from a 70 character set with real randomness. Use a manager, do not memorise it. |
Note the third row. A four word passphrase has more entropy than P@ssw0rd! by a factor of billions, despite looking simpler to a human and failing many corporate complexity rules. This is why NIST SP 800-63B now advises against forced composition rules and periodic expiry, and recommends length plus a check against known breached passwords instead.
Beyond security
Every category on ConvertNow, free and updated as new tools launch.
Security writing without the scare tactics
Practical explanations of hashing, headers, certificates and consent, aimed at people who have to ship something this week.
Security tools online questions, answered plainly
Where the data goes, which algorithms to trust, and what these tools cannot do.
Which of these tools send data over the network?
Is it actually safe to generate a password here?
crypto.getRandomValues, the browser cryptographic random number generator, and the result is never transmitted. If you would rather not trust any website with this, a password manager generating locally is the stronger habit and we would recommend it.Can you reverse a hash back to the original?
Why do you still offer MD5 and SHA-1 if they are broken?
Should I use SHA-256 to store passwords?
Is the generated privacy policy legally sufficient?
What is the strength meter actually measuring?
Do you keep a record of the domains I look up?
How to use these safely
Three things worth holding onto, whichever tool on this page you reach for.