What is stored inside a bcrypt hash
Bcrypt is a password hashing function designed to make each password guess deliberately expensive. Its encoded result contains a version marker, cost factor, salt, and derived hash. A verifier reads those parameters from the stored string, hashes the candidate password the same way, and performs a safe comparison. The original password is not decrypted from the result.
A fresh random salt is generated for every PagesTools result. Consequently, hashing the same password twice should produce different strings while both remain valid for that password. Salts prevent identical passwords from sharing an obvious stored value and defeat one precomputed table, but they are not secret and do not compensate for weak passwords or poor server controls.
The cost is logarithmic. Raising it by one approximately doubles the underlying work, so a setting of 13 is roughly twice as expensive as 12 on the same implementation. This slows attackers but also slows legitimate sign-in and consumes server resources. The suitable value is the highest one your production environment can sustain within its latency and capacity budget.
Generating a useful test value
Enter a test password, select a cost from the supported range, and generate the hash. Copy the complete output, including its leading version and cost fields. Do not trim characters or store it in a database column that is too short. A common safe allocation is at least 60 characters for current bcrypt strings, with additional room if a framework may add metadata.
The tool enforces bcrypt’s 72-byte password boundary to prevent silent truncation. Bytes are not the same as visible characters: UTF-8 emoji and many non-Latin characters require multiple bytes. Some historical libraries truncate longer inputs, which can make distinct passwords equivalent after the limit. Rejecting oversized input makes that behavior explicit and supports safer migration tests.
Validate the output with the same maintained library and runtime used by the application. Confirm both successful and failed comparisons, Unicode input policy, maximum length behavior, and database storage. A browser-generated sample can help fixture creation, but production account creation should hash on the trusted server so policy enforcement and rate controls remain centralized.
Cost selection and authentication boundaries
Benchmark on representative production hardware instead of choosing a cost solely from an online recommendation. Measure normal verification, concurrent sign-ins, password resets, and denial-of-service exposure. Revisit the value as hardware and traffic change. Many systems upgrade an older cost after the next successful login, avoiding a disruptive bulk rehash that would require plaintext passwords.
Bcrypt handles password derivation, not the rest of authentication. Applications still need secure transport, session management, multifactor options, breached-password screening, account recovery, rate limiting, logging, and careful error messages. A valid hash does not make a database or login route secure. Use the password API of a maintained framework whenever one is available.
New designs should evaluate current platform guidance, which may prefer Argon2id or scrypt because they can be memory-hard. Bcrypt remains widely supported and can be appropriate for compatibility and migrations when its limits are understood. Do not convert an existing bcrypt hash into another password hash; migration normally requires verifying the user’s password and hashing that plaintext under the new policy.
Local processing, secrets, and limitations
Generation happens locally in your browser with a client-side bcrypt library. PagesTools does not need to upload the entered password. Despite that boundary, a browser page is not a secure vault: extensions, clipboard managers, screen sharing, local malware, and other people using the device may observe the field or result.
Use synthetic test passwords rather than real account credentials. Never paste a password that protects email, banking, production infrastructure, recovery material, or another person’s account. The generated value is suitable for development fixtures and controlled migration checks, but server-side authentication should generate salts, enforce policy, and hash inside the application’s protected environment.