Security & Privacy

Security tools prevent unauthorized access to your accounts and systems; privacy tools control what data exists about you and who can see it. The free tools in this category handle both concerns without sending your data anywhere — they run in the browser, require no account, and work offline after the page loads. Whether you are a developer hardening a web application, a sysadmin provisioning credentials, or someone who just wants to know whether their passwords are any good, there is a concrete tool here for your exact situation.

What 'Security & Privacy Tools' Actually Means (and What This Category Covers)

Security and privacy are related but not the same. Security is about blocking unauthorized access — someone who should not get in, does not. Privacy is about limiting what data exists and who can reach it — even authorized systems should not know more than necessary. These two goals overlap constantly, which is why tools for both live in the same category.

The 23 tools here fall into four practical buckets. Credential management covers password generators, passphrase generators, bulk generators, and 2FA utilities — anything that produces or evaluates secrets you authenticate with. Cryptographic utilities covers hashing, nonces, CSRF tokens, and key exchange explainers — tools developers use when building systems that handle secrets. HTTP security headers covers HSTS and CORS header builders — the configuration layer that browsers and servers negotiate before any data moves. Education and reference covers crack time estimators, the OWASP checklist, and the Diffie-Hellman explainer — tools that build understanding, not just output.

A point worth making explicit: every tool here is client-side. Your passwords, passphrases, and tokens are generated in your browser tab and never transmitted to a server. That is not a marketing claim; it is a design requirement for any tool in this category that handles sensitive values. No account is required, and after the page loads, most tools continue to function without a network connection.

These tools are built for four audiences: developers who need cryptographic primitives and correct header syntax; sysadmins who need to provision credentials at scale; privacy-conscious everyday users who want to audit what they expose online; and students learning applied security concepts. If you fall into more than one category, you will use more than one bucket.

Credential Security: Passwords, Passphrases, and 2FA Codes

Credential stuffing — where attackers take leaked username/password pairs from one breach and try them on unrelated services — succeeded against billions of accounts in recent years precisely because people reuse passwords. The defense is simple in principle and tedious in practice: every account gets a unique, high-entropy credential.

A password generator and a passphrase generator solve the same entropy problem differently. A password generator produces a string of random characters — uppercase, lowercase, digits, symbols — that is hard to brute-force but also hard to type or remember. A passphrase generator produces a sequence of random words (typically four to six) that carries comparable entropy while being far easier to recall and type manually. The tradeoff is memorability versus compactness: use random character passwords inside a password manager where you never type them, and use passphrases for anything you authenticate by hand — disk encryption keys, password manager master passwords, Wi-Fi credentials you enter on a TV. The Password Generator handles the former; the Passphrase Generator handles the latter.

If you need more control — minimum symbol counts, exclusion of ambiguous characters like 0 and O, or specific length constraints — the Advanced Password Generator exposes all of those options. Most users will not need them, but developers building password policies for a product will.

One use case that gets overlooked: bulk credential generation. When you are provisioning user accounts for a staging environment, seeding a test database, or creating service accounts in bulk, generating passwords one at a time is slow. The Bulk Password Generator produces a configurable batch in one operation — you set the count, length, and character rules, then export the list. This is an IT and developer workflow, not a consumer one, but it saves real time.

For users who find fully random strings unworkable even with a password manager — because their workplace policy requires them to know the password, for example — the Memorable Password Generator produces credentials that mix randomness with word-like patterns, sitting between a pure random string and a passphrase.

On 2FA: Time-based One-Time Passwords (TOTP) work by combining a shared secret with the current timestamp to produce a six-digit code that changes every 30 seconds. The 2FA Code Generator implements this locally, which is useful when you are testing a TOTP integration in your own app, verifying that a secret key you have backed up still produces the right codes, or just learning how the algorithm works without trusting a third-party app with your secrets.

Understanding Password Strength: Crack Time Estimation

Crack time estimators do not tell you whether a specific password has been leaked — that requires a breach database lookup, which is a different tool. What they do is estimate how long a given password would survive a brute-force or dictionary attack, given realistic assumptions about attack speed.

The two scenarios that matter most are offline attacks (an attacker has stolen a password database and is cracking it at GPU speed — billions of guesses per second) and online throttled attacks (an attacker is guessing against a live login form with rate limiting — maybe ten attempts per second). A password that would survive an online attack for years might fall to an offline attack in minutes. The Password Crack Time Estimator shows both scenarios so you can make an informed call.

The most common misconception is that special characters make a password strong. They help, but not as much as length. A 16-character lowercase-only random string has more entropy than an 8-character string with symbols. The other misconception is that complexity requirements — the ones that force you to include at least one capital and one number — produce strong passwords. They force users toward predictable substitutions (password becomes P@ssw0rd) that crack almost instantly. Use the estimator to test this yourself: it is a better teaching moment than any explanation.

Practical workflow: generate a credential with one of the password tools, paste it into the estimator, and if the offline crack time is under a week, regenerate with a longer length or more entropy. Do this once and you will internalize what good entropy actually looks like.

Hashing and Cryptographic Primitives for Developers

This bucket is aimed at developers. If you are building a system that stores passwords, issues tokens, or participates in key exchange, you need to understand these primitives before you implement them.

Bcrypt is still the standard recommendation for password hashing in 2026 for most applications. It is slow by design — the cost factor controls how many iterations the hash function runs, letting you tune it to keep pace with faster hardware. Critically, bcrypt salts automatically, which means two identical plaintexts produce different hashes, defeating rainbow table attacks. When you are debugging an authentication system and need to verify that a plaintext password matches a stored bcrypt hash without writing code, the Bcrypt Hash Verifier does exactly that in the browser.

A cryptographic nonce is a value used exactly once. Nonces appear in authentication protocols, encrypted messages, and API requests to prevent replay attacks — an attacker who captures a valid request cannot reuse it if the server validates nonce uniqueness. The critical rule: never reuse a nonce. Reusing a nonce in certain encryption schemes (AES-GCM, for example) completely breaks confidentiality. The Cryptographic Nonce Generator produces cryptographically random values you can use in tests or as examples when documenting a protocol.

If you have ever wondered why HTTPS is hard for an attacker to intercept even though the initial connection is unencrypted, the answer is Diffie-Hellman key exchange. Two parties can negotiate a shared secret over a public channel without ever transmitting the secret itself. The Diffie-Hellman Key Exchange Explainer walks through the math step by step with interactive values, which builds genuine intuition for why TLS works rather than just memorizing that it does.

Cross-Site Request Forgery (CSRF) is an attack where a malicious page tricks a logged-in user's browser into making a state-changing request to another site — transferring funds, changing an email address — because the browser automatically includes session cookies. A CSRF token defeats this by requiring each form submission to include a secret value that only the legitimate site knows. The CSRF Token Generator produces random tokens you can use when building and testing this protection. Developers shipping web apps should cross-reference this against the OWASP checklist, where CSRF falls under the Broken Access Control and Security Misconfiguration categories.

HTTP Security Headers: The Invisible Layer Most Sites Skip

HTTP response headers tell the browser how to behave when it receives a page. Security headers specifically tell the browser what it is and is not allowed to do — follow redirects to HTTP, load resources from third-party origins, allow cross-origin requests. They are invisible to users and frequently misconfigured or absent entirely.

HSTS (HTTP Strict Transport Security) tells a browser that this site should only ever be accessed over HTTPS, for a specified duration. Once a browser sees an HSTS header, it will refuse to make unencrypted connections to that domain, even if the user types http:// directly. The gotcha is the preload directive: adding your domain to the browser preload list is a one-way door — it can take months to get removed, and if your HTTPS setup breaks, your site becomes unreachable. The HSTS Header Generator lets you configure the max-age, includeSubDomains flag, and preload flag, then outputs the exact header string ready to paste into your server config.

CORS (Cross-Origin Resource Sharing) controls which external origins can make requests to your API. A permissive CORS configuration — Access-Control-Allow-Origin: * — is one of the most common API misconfigurations because it is easy to set and easy to forget. Depending on your API's authentication model, it can allow malicious sites to make authenticated requests on behalf of your users. The CORS Header Builder walks you through the relevant options — allowed origins, methods, headers, credentials — and outputs a validated header set. After generating headers here, verify them against your deployed site using browser DevTools (Network tab, inspect response headers on any request) or a dedicated security scanner.

Developers working on HTTP configuration will also find value in the broader Networking Tools category, which covers IP analysis, DNS lookups, and related network diagnostics.

Knowing Your Exposure: IP Address and Network Awareness

Your public IP address is what every website and server you connect to sees. It reveals your approximate geographic location (city-level, sometimes more precise), your ISP, and whether your connection routes through a known VPN or proxy. It does not reveal your street address or identity directly, but combined with other signals, it narrows you down considerably.

The IP Address Checker shows you exactly what a site sees when you connect — your IPv4 address, your IPv6 address if your device has one, geolocation data, and whether your connection is flagged as a VPN or proxy exit node. Check it before enabling a VPN or privacy proxy, then check it again after. If your IPv6 address still shows after enabling a VPN, your VPN has an IPv6 leak and is not actually hiding your traffic for dual-stack connections. Many users have no idea their device broadcasts an IPv6 address at all, which is why this check is worth running regularly.

A useful privacy audit sequence: check your IP, note what it reveals, then assess whether the services you use justify that exposure. This is a starting point, not a complete audit — your browser fingerprint, cookies, and DNS resolver reveal additional information that an IP check alone will not surface.

The OWASP Top 10: Using a Checklist as a Security Mindset Tool

OWASP (Open Web Application Security Project) publishes a consensus list of the ten most critical web application security risks, updated periodically based on real-world data from security firms and bug bounty programs. It is the closest thing the industry has to a universal baseline for web application risk. If your application avoids all ten categories, you have addressed the overwhelming majority of attack vectors seen in practice.

The OWASP Top 10 Checklist here is meant to be used as a pre-launch audit, not a compliance checkbox. Go through it before deploying a new feature, not after a breach. The items most frequently failed in real audits are: injection (SQL, command, and LDAP injection through unsanitized input), broken authentication (weak session management, missing 2FA), security misconfiguration (default credentials left in place, verbose error messages in production, missing security headers), and vulnerable and outdated components (libraries with known CVEs that never got updated).

The checklist connects directly to other tools here. If you are working through the Broken Access Control items, the CSRF Token Generator addresses exactly the protection pattern required. If you are on Security Misconfiguration, the HSTS and CORS generators produce the header values that item expects. The checklist tells you what; the other tools help you build it.

Who benefits most: developers shipping web applications before they go to production, freelancers building client sites who do not have a dedicated security reviewer, and security students working through structured learning.

Free vs Paid Security Tools: Where the Line Actually Is

Free client-side tools do certain things genuinely well: generating credentials, estimating entropy, building header strings, explaining cryptographic concepts, checking network exposure. None of those tasks requires an ongoing service — they are operations you run when you need them and they have a clear output.

What free tools cannot replace: real-time threat monitoring that alerts you when your credentials appear in a new breach; vulnerability scanning that crawls your deployed application looking for injection points; managed SIEM (Security Information and Event Management) that aggregates logs and surfaces anomalies; breach alerting that watches for your email address or domain in data dumps. These are ongoing services with infrastructure costs, and free versions are either limited or monetized in ways that should make you cautious.

If you are protecting a production application, a business with user data, or sensitive systems at scale, you need paid tooling alongside these free utilities. The free tools here are not a replacement for that — they are a complement, handling the generation and education layer that paid tools typically do not cover anyway.

One important distinction: free open-source utility versus freemium app that monetizes your behavior. A free browser-side password generator with published source code is structurally different from a free app that uploads your passwords to generate 'strength scores'. The red flags to watch for in any security tool: passwords or tokens are processed server-side, the site does not use HTTPS, source code is not available, or an account is required to use the tool.

Building a Personal Security Workflow with Free Tools

Security is more useful as a practiced habit than as a one-time project. The following workflow applies the tools in this category in a logical sequence, whether you are an individual or a developer shipping software.

Step 1: Audit existing passwords. Take a few passwords you currently use — especially older ones — and run them through the Password Crack Time Estimator. If any of them show offline crack times under a day, they need to be replaced immediately.

Step 2: Generate fresh credentials. Use the Password Generator or Advanced Password Generator for anything stored in a password manager. Use the Passphrase Generator for anything you type manually — disk encryption passphrases, password manager master passwords, SSH key passphrases. Memorable Password Generator works for the small set of passwords you need to know but find random strings unmanageable.

Step 3: Enable 2FA everywhere you can. Use the 2FA Code Generator to understand how TOTP works and to test backup codes if you are ever in a situation where your authenticator app is unavailable. Understanding the mechanism makes you less likely to get locked out.

Step 4 (developers): Run the OWASP checklist before deployment. Generate correct HSTS and CORS headers using the builders here. Verify your authentication layer handles CSRF tokens. Check that your password storage uses bcrypt with an appropriate cost factor. These steps take under an hour and address the categories most commonly exploited in real attacks.

Step 5: Periodically check your network exposure. Run the IP Address Checker whenever you switch networks or VPN providers. Look for IPv6 leaks. Verify that your VPN exit node is where you expect it to be. Do this every time you set up a new device or change your network configuration.

The principle underneath all of this: each tool addresses a specific, concrete failure mode. Weak passwords, credential reuse, missing 2FA, incorrect headers, misconfigured APIs — these are all things that happen not because people do not care but because they did not have a quick way to do the right thing. These tools are that quick way.