Frequently Asked Questions

The Web Crypto API is a W3C standard that exposes cryptographic primitives to JavaScript — including secure random number generation (crypto.getRandomValues), hash functions (SHA-256, SHA-512), HMAC, PBKDF2, and digital signature verification. Unlike JavaScript-only crypto libraries, it is implemented in native code by the browser vendor, making it both faster and more trustworthy. BetterPass relies on it as the foundation for most of its tools.

Client-side cryptography means all encryption, hashing, and key generation happens on your device using your browser's native capabilities. Your data never travels over the network, so there is no risk of interception, server-side breach, or third-party access. This approach eliminates entire categories of vulnerabilities — no man-in-the-middle attacks on tool data, no database leaks of generated passwords, and no server logs that could be subpoenaed. Every tool on BetterPass follows this model.

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.

Per NIST SP 800-63B, mandatory periodic password changes are no longer recommended unless there is evidence of compromise. Frequent forced changes lead people to choose weaker, incremental variations (like Password1! → Password2!). Instead, change passwords only when: you know or suspect the account was compromised, a service you use suffered a breach, you shared the password with someone, or you used the password on a compromised device. Enable breach monitoring through services like Have I Been Pwned so you know when to act.

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 an automated attack where hackers use username-password pairs stolen from one service and try them across hundreds of other sites. Since many people reuse passwords, attackers achieve login on 0.1-2% of targeted accounts — enough to compromise millions of accounts from a single breach. Unlike brute-force attacks, credential stuffing uses known credentials, making it harder to detect. The only defense is never reusing passwords. Enable multi-factor authentication wherever possible as a second layer of protection.

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.

Entropy measures how unpredictable your password is, expressed in bits. Each additional bit of entropy doubles the number of guesses an attacker must try. A password with 80 bits of entropy requires 2⁸⁰ attempts to brute-force — infeasible with current technology. The formula is log2(pool_sizelength). See the Entropy Calculator to compute exact values for your passwords.

A passkey is a FIDO2/WebAuthn credential backed by public-key cryptography where the private key never leaves your device. Unlike passwords, passkeys are phishing-resistant because they are scoped to the website origin and never sent to a lookalike site. Passkeys increasingly replace passwords for consumer accounts and provide stronger security through origin-bound key pairs rather than shared secrets.

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.

Per NIST SP 800-63B: minimum 8 characters with no arbitrary maximum, allow all ASCII and Unicode characters, no mandatory composition rules (no required symbols or numbers), check passwords against known breach lists, no periodic rotation unless compromised, support copy-paste in password fields, and rate-limit authentication attempts. Use the Password Policy Tool to build compliant policies.

Keyboard patterns are sequential key presses on a QWERTY keyboard — like qwerty, asdfgh, or 1qaz2wsx. These appear in nearly every password cracking dictionary because they are extremely common. Even a long keyboard pattern is weak because it follows a predictable path. The Password Generator includes a "no keyboard patterns" option to avoid this 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 (the winner of the Password Hashing Competition) is resistant to GPU and ASIC attacks because it is memory-hard. It requires a configurable amount of memory (typically 64MB or more) to compute a single hash. GPUs excel at parallel computation but have limited memory bandwidth — a consumer GPU with 12GB of RAM can only compute ~200 Argon2 hashes simultaneously, compared to millions of SHA-256 hashes. This makes GPU-based brute-force economically infeasible. Argon2 also offers configurable time cost and parallelism, giving defenders flexibility to increase difficulty as hardware improves. Try it with the Argon2 tool.

A salt is unique random data added to each password before hashing. Without salts, identical passwords produce identical hashes — an attacker could precompute a rainbow table mapping common passwords to their hashes and crack thousands of accounts instantly. With unique salts per user, the attacker must brute-force each password individually, multiplying the work factor by the number of users. Modern password hashing algorithms like Bcrypt, Argon2, and PBKDF2 handle salting automatically.

Hashing is a one-way function producing a fixed-length digest that cannot be reversed to recover the original data. Encryption is two-way — data scrambled with a key can be decrypted back to plaintext. Use hashing for integrity verification, password storage, and digital signatures. Use encryption for confidentiality — protecting data in transit (TLS) or at rest. Never confuse the two: hashing does not protect secrecy, and encryption without integrity checking does not provide tamper detection.

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 a one-way function that takes any input and produces a fixed-length digest. It has four essential properties: deterministic (same input always produces the same output), fast to compute, preimage-resistant (cannot reverse the hash to recover the input), and collision-resistant (two different inputs should never produce the same hash). Try the Hash Generator to see hashes in action.

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 due to widespread hardware acceleration (SHA-NI), while SHA-3 offers post-quantum readiness and is used in Ethereum for address generation. 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.