Frequently Asked Questions

The Web Crypto API is your browser's built-in cryptography engine — a W3C standard that gives JavaScript access to secure random number generation, SHA hashing, HMAC, PBKDF2, and digital signature verification. Unlike JavaScript-only crypto libraries, it runs in native code written by the browser vendor (Google, Apple, Mozilla), making it faster and more trustworthy than any third-party library. BetterPass uses it as the foundation for our hashing tools, password generator, and encryption features.

When we say client-side cryptography, we mean every encryption, hash, and key generation happens right on your device using your browser's native capabilities — not on a remote server. Your data never touches the network, which means no risk of interception, no server breach, no third-party access. This eliminates entire categories of attacks: no man-in-the-middle on tool data, no database leaks of generated passwords, no server logs to subpoena. It's the same privacy-first architecture used by modern password managers.

No. BetterPass never sends your passwords, hashes, tokens, or any tool data to a server. Every tool runs entirely in your browser using the Web Crypto API or audited client-side libraries. There is no server-side database, no logging, and no analytics that capture tool inputs. What you do in your browser stays in your browser.

Yes. Once the page loads, most tools work completely offline. All cryptographic and data processing uses your browser's built-in capabilities. The only exception is the Breach Checker, which needs network access to query the Have I Been Pwned API using a privacy-preserving k-anonymity model.

BetterPass is supported through Google AdSense and remains completely free to use with no account required. We do not sell your data, offer premium tiers, or use your tool inputs for monetization. Our revenue covers hosting, development, and ongoing security audits.

Your data stays safe because your data never reaches our servers. A server compromise would expose static website files and ad scripts — but no passwords, hashes, tokens, or user-generated content. There is no database of tool results to steal. We also pin all third-party dependencies to specific versions to minimize supply-chain risk.

We keep dependencies minimal. For core algorithms, BetterPass relies on the browser-native Web Crypto API — no third-party code needed. For algorithms not available in the Web Crypto API, we use audited open-source libraries: @noble/hashes for SHA-3, bcryptjs for Bcrypt, and @noble/ciphers for XChaCha20-Poly1305 (used in PASETO). All dependencies are pinned to specific versions and reviewed for security.

The most common mistakes are reusing passwords across accounts, using short or simple passwords, relying on personal information (birthdays, pet names), and falling for phishing attacks. Password reuse is the most dangerous — a breach at one service exposes every account that shares that password. Other frequent errors include writing passwords on sticky notes, storing them in unencrypted documents, and choosing keyboard patterns like qwerty or sequential characters like 123456. The Password Strength Checker can evaluate your current passwords.

Good news: you probably don't need to change your password every 90 days. Per NIST SP 800-63B, mandatory periodic changes are no longer recommended — they found it just pushes people toward weak variations like Password1! → Password2!. Instead, change a password only when you know or suspect the account was compromised, a service you use suffered a breach, or you shared it with someone. Use our Breach Checker to monitor if your passwords have been exposed — it uses the same k-anonymity privacy model as Have I Been Pwned, and your full password never leaves your device.

Yes, absolutely. Every account needs a unique password. When you reuse a password, a breach at any one service exposes all accounts sharing that password. With billions of credentials exposed in data breaches, attackers use credential stuffing — trying stolen username-password pairs across dozens of popular services — to hijack accounts. The only practical way to maintain unique passwords for every account is a password manager. It stores each password encrypted behind a single master passphrase you need to remember.

Credential stuffing is when hackers take username-password pairs stolen from one site and try them across hundreds of others. Because so many people reuse passwords, attackers succeed on 0.1–2% of accounts — which means millions of accounts compromised from a single data breach. Unlike brute-force attacks, credential stuffing uses real credentials, making it much harder to detect. The only real defense? Never reuse passwords across accounts. A password generator combined with a password manager makes this easy. Enable multi-factor authentication wherever possible as a second layer.

A password is a random string of characters (letters, numbers, symbols). A passphrase is a sequence of random words separated by delimiters. Passphrases are easier to remember and type, while random passwords can achieve higher entropy per character. Both are secure when generated cryptographically. Try the Password Generator for passwords or the Passphrase Generator for memorable secrets.

Per NIST SP 800-63B: minimum 8 characters for user-chosen passwords with no maximum. For generated passwords, 16+ characters provides excellent security. For high-value accounts (email, banking, password manager master), use 20+ characters or a 5+ word passphrase (~65-90 bits entropy). Use the Entropy Calculator to measure your password's strength.

Password entropy is a fancy way of measuring how unpredictable your password is — think of it as a "guessability score" expressed in bits. Every additional bit of entropy doubles the number of guesses an attacker needs. A password with 80 bits would take quadrillions of years to crack with today's hardware. The formula is log2(pool_sizelength), but you don't need to do the math — our Entropy Calculator shows you instantly for any password or passphrase.

A passkey is like a digital key that lives only on your device — it uses public-key cryptography (FIDO2/WebAuthn) where the private key never leaves your phone or laptop. Unlike passwords, passkeys are phishing-resistant by design: they're tied to the exact website origin, so a fake login page can't steal them. That said, passwords aren't going away — most services still rely on them, and a strong password generator combined with a password manager is still your best bet for comprehensive account security.

The Breach Checker uses a k-anonymity model. Only the first 5 characters of your password's SHA-1 hash are sent to the Have I Been Pwned API. The API returns all matching hash suffixes, and the comparison happens locally in your browser. Your full password, full hash, and plaintext are never transmitted.

NIST SP 800-63B sets the gold standard for password policies. The key requirements: minimum 8 characters with no arbitrary maximum, allow all ASCII and Unicode characters, no mandatory composition rules (forced symbols and numbers just annoy users), check all passwords against known breach lists, and no forced rotation unless there's evidence of compromise. Use our Password Policy Tool to generate a fully compliant policy in seconds.

Keyboard patterns like qwerty, asdfgh, and 1qaz2wsx are among the first things attackers try — they're in every password cracking dictionary. Even a long keyboard sequence is weak because it follows a predictable path across the keyboard. Our Password Generator includes a "no keyboard patterns" option that ensures your passwords avoid this common vulnerability entirely.

Built-in password managers in Chrome, Safari, Firefox, and Edge are reasonably safe for most users. They encrypt saved credentials using the device's operating system keychain and sync them through the browser provider's infrastructure. For maximum security, a dedicated password manager like Bitwarden or 1Password is preferred because it offers zero-knowledge architecture (your master password is never known to the provider), stronger encryption, breach monitoring, and cross-platform support. Browser managers are better than nothing but lack advanced security features.

While no software is completely invulnerable, reputable password managers use zero-knowledge encryption — your vault is encrypted with your master password before it ever leaves your device. The provider stores only encrypted blobs that they cannot decrypt. A server breach would yield only encrypted data. The most realistic risk is your device being compromised with malware that captures your master password as you type it. Enable multi-factor authentication on your password manager account and keep your devices updated to minimize this risk.

Argon2 won the Password Hashing Competition for one big reason: it's memory-hard. Each hash requires a configurable chunk of memory (64MB or more by default), and GPUs — despite being great at parallel computation — have limited memory bandwidth. A consumer GPU with 12GB of RAM can only compute about 200 Argon2 hashes at once, compared to millions of SHA-256 hashes. That makes GPU brute-forcing economically infeasible. Try our Argon2 tool to experiment with the settings yourself.

A salt is random data added to each password before hashing, and it solves a huge problem: without salts, anyone with the same password gets the same hash. Attackers can precompute a rainbow table mapping common passwords to their hashes and crack thousands of accounts instantly. With unique salts, they'd have to brute-force each password individually — multiplying the work by millions. Every modern algorithm handles this automatically. Check our Bcrypt, Argon2, and PBKDF2 tools to see how salts are encoded in the hash output.

Hashing is one-way; encryption is two-way. Hashing turns data into a fixed-length fingerprint that can't be reversed — use it for password storage, integrity checks, and digital signatures. Encryption scrambles data with a key so only the key holder can read it — use it for confidentiality (TLS, file encryption). The confusion is dangerous: hashing doesn't protect secrecy, and encryption alone doesn't detect tampering. See the difference in practice with our hashing tools and encoding tools.

Your choice depends on the use case. For file integrity or checksums, use SHA-256 or SHA-512. For password storage, use Bcrypt, Argon2, scrypt, or PBKDF2. For message authentication, use HMAC-SHA256. Use the Hashing Tools page to explore all available algorithms and compare their properties.

A cryptographic hash is like a digital fingerprint — it takes any input and produces a fixed-length digest that's unique to that input. Four essential properties make it work: deterministic (same input = same hash every time), fast to compute, preimage-resistant (you can't reverse it), and collision-resistant (two different inputs shouldn't produce the same hash). Try our Hash Generator to see how different inputs produce completely different outputs.

No. MD5 has known collision attacks that can produce two different inputs with the same hash in seconds on consumer hardware. Never use it for security-sensitive purposes: password storage, digital signatures, certificate validation, or any scenario where an attacker could craft a collision. The only acceptable use for MD5 today is non-security checksums — detecting accidental file corruption in legacy systems. Use the MD5 tool for legacy checksums, but switch to SHA-256 for anything security-related.

A salt is unique random data added to each input before hashing. It prevents rainbow table attacks and ensures identical passwords produce different hashes. Bcrypt, scrypt, and PBKDF2 automatically generate and include salts in their output format. See the Bcrypt, scrypt, and PBKDF2 tools for details on how each handles salting.

SHA-2 uses the Merkle-Damgård construction while SHA-3 uses the Keccak sponge construction. SHA-3 is inherently resistant to length extension attacks and was designed as a backup if SHA-2 were ever broken. Both are NIST-approved. SHA-2 is generally faster thanks to 64-bit-optimized designs and SHA-NI acceleration for SHA-1/SHA-256, while SHA-3 offers post-quantum readiness and native length-extension resistance (note Ethereum uses the pre-standardization Keccak-256 variant, which differs from NIST SHA3-256). Compare outputs using the SHA-256 and SHA3-256 tools.

Argon2 (specifically Argon2id) is the recommended choice for new systems — it won the PHC competition and provides configurable memory-hardness, time cost, and parallelism that resist GPU and ASIC attacks. Bcrypt is a solid choice with broad library support and automatic salting. PBKDF2 is widely available but lacks memory-hardness, making it more vulnerable to GPU attacks — use a high iteration count (600k+) if PBKDF2 is your only option. Each has a dedicated tool: Argon2, Bcrypt, PBKDF2.

Base64 is used whenever binary data needs to be transmitted or stored in a medium that only supports text. Common use cases include: embedding images in HTML or CSS (data URIs), attaching files to email (MIME), encoding binary payloads in JSON (like JWTs), storing cryptographic keys and certificates (PEM format), and transmitting data in URL query parameters (using the URL-safe variant). Use the Base64 tool to encode and decode data.

Base64 is reversible because it is a deterministic encoding scheme with no key. It simply maps every 3 bytes of input (24 bits) into 4 Base64 characters (6 bits each). The mapping is defined by a public standard (RFC 4648) that anyone can look up. Decoding is the reverse process — mapping each Base64 character back to its 6-bit value and reassembling the original bytes. This is fundamentally different from encryption, where reversing requires a secret key. The Base64 tool lets you see both directions instantly.

Encoding transforms data into a different format for compatibility (like Base64 for email attachments or URL encoding for web requests). It uses no key and is trivially reversible by anyone. Encryption transforms data using a secret key and is designed to be reversible only by key holders. Encoding preserves data integrity across systems; encryption preserves confidentiality against unauthorized parties. Explore the Encoding Tools to see the difference in practice.

Base64 is the most common encoding for binary-to-text — used in email attachments (MIME), data URIs, and JWT payloads. Base58 excludes visually similar characters (0/O/I/l) and is used in Bitcoin addresses and cryptocurrency. Base32 uses only uppercase letters and digits, making it case-insensitive — used for DNS records, TOTP secrets, and OpenPGP. Use the Base64, Base58, and Base32 tools to convert between formats.

URL encoding (percent-encoding) converts characters that are not allowed in URLs into a % followed by two hex digits. It ensures that special characters like spaces (%20), ampersands (%26), and non-ASCII characters are properly transmitted in web requests. It is essential for query parameters, form submissions, and REST API calls. Try the URL Encoder/Decoder to see how URLs are encoded.

Hex (hexadecimal) is ideal when human readability matters — each byte becomes two hex characters (0-9, a-f). Hash digests are universally displayed in hex (e.g., sha256sum output). Base64 is more space-efficient, encoding 3 bytes into 4 characters (33% overhead vs 100% for hex). For checksums and debugging, use hex. For transmission and storage efficiency, use Base64. Compare both with the Hex and Base64 tools.

Base64URL is a variant of Base64 that replaces + with - and / with _, and omits padding = characters. This makes it safe for use in URLs and filenames without additional encoding. It is used in JWT (JSON Web Tokens), OIDC (OpenID Connect), and PASETO tokens. The Base64 tool includes a "URL safe" option that converts to and from Base64URL format.

JWT is not ideal for all scenarios. Avoid JWTs when: you need to revoke individual tokens (JWTs are self-contained and cannot be revoked without a server-side blocklist), your tokens need to carry large payloads (the entire token is transmitted on every request), you lack a secure way to distribute signing keys, or you are building simple server-to-server communication within a trusted network (opaque tokens or session identifiers are simpler). For session management where revocation is critical, consider opaque tokens stored server-side with the Opaque Token Generator.

JWT (JSON Web Token) is the industry standard with broad ecosystem support but suffers from algorithm confusion vulnerabilities and complex configuration. PASETO (Platform-Agnostic Security Token) is a newer design that eliminates algorithm negotiation — each version uses a fixed, secure algorithm pair. PASETO v4 uses XChaCha20-Poly1305 for encryption and Ed25519 for signatures, reducing the attack surface. Inspect both formats with the JWT Decoder and PASETO Decoder.

HS256 (HMAC-SHA256) uses a shared secret key for both signing and verification — fast and simple but requires both parties to share the secret. RS256 (RSA-SHA256) uses a private key for signing and a public key for verification — enabling third-party verification without sharing secrets. RS256 is preferred for server-to-server communication where the verifying party should not be able to create valid tokens. Use the JWT tool to decode and inspect both algorithm types.

OIDC (OpenID Connect) is the modern choice for most applications — it uses JSON/JWT, is REST-friendly, and works well with SPAs and mobile apps. SAML (Security Assertion Markup Language) uses XML and is primarily used in enterprise single sign-on (SSO) environments with identity providers like ADFS or Okta. For new projects, prefer OIDC. For enterprise SSO integration, you may need SAML. Decode SAML assertions with the SAML Decoder and explore OIDC with the OIDC Decoder.

An opaque token is a random string that serves as a reference to stored session data on the server. Unlike JWT or PASETO, opaque tokens contain no internal structure or claims — they are simply a unique identifier. The server must look up the associated session data on each request. Opaque tokens are commonly used for session cookies and access tokens in OAuth 2.0, and they can be revoked by deleting the server-side session. Generate them with the Opaque Token Generator.

Token introspection (RFC 7662) is a protocol that allows a resource server to query an authorization server about the validity and metadata of an access token. The resource server sends the token to the authorization server's introspection endpoint and receives a JSON response with active status, claims, and expiration. This is commonly used in OAuth 2.0 deployments where resource servers need to verify tokens without sharing the signing key. Explore token formats with the Token Tools.

Yes — binary formats like MessagePack, CBOR, and BSON are generally faster to parse and more compact than JSON. JSON parsing involves string-to-value conversion for every field, while binary formats decode directly to typed values. In benchmarks, MessagePack encoding is typically 2-3x faster than JSON for comparable data, and CBOR with deterministic encoding offers similar gains. The exact speedup depends on data complexity and the specific format. Try the MessagePack and JSON tools to compare sizes and performance.

Protocol Buffers (Protobuf) is a language-neutral, platform-neutral mechanism for serializing structured data, developed by Google. You define your data structure in a .proto file, and Protobuf generates code to efficiently read and write your data in various languages. Protobuf is used extensively in gRPC, internal microservices, and systems requiring high-throughput serialization. Use the Protobuf tool to encode and decode messages without a schema file.

In most implementations, MessagePack is marginally faster for simple JSON-like data due to its simpler encoding rules. CBOR offers more features (deterministic encoding, bignums, tagged types, indefinite-length arrays) which can add parsing overhead. However, for the common subset of data types, the performance difference is negligible. Choose CBOR when you need RFC compliance, deterministic encoding for hash verification, or IoT interoperability. Choose MessagePack for the simplest JSON-to-binary migration path. Compare both with the CBOR and MessagePack tools.