Bcrypt generator

Bcrypt generator is a free tool that creates a bcrypt password hash from any string input for secure password storage.

What is bcrypt, and is it still safe?

Bcrypt is a password-hashing algorithm that remains acceptable for password storage when configured with a suitable cost, although newer systems often prefer Argon2id. Niels Provos and David Mazières designed bcrypt in 1999, using the Blowfish cipher's key-scheduling process to make each password guess deliberately expensive.

Hashing is one-way, so an application checks a password by hashing a candidate under the stored parameters rather than recovering the original. Unlike general-purpose algorithms such as SHA-3, bcrypt produces a self-contained, fixed-length encoded record containing its version, cost, salt and checksum.

A standard bcrypt record is 60 ASCII characters long. Its checksum represents 184 bits and appears as 31 characters in bcrypt's own Base64-style encoding. Bcrypt is not considered cryptographically broken, but it has an age-related limitation: traditional implementations process no more than 72 input bytes. Argon2id also provides memory-hard protection that bcrypt does not.

How do I use the Bcrypt generator?

Enter the string that needs hashing, run the generator and copy the value shown in the Bcrypt Hash result field. Store the complete result rather than extracting only the final checksum.

1. Use the exact password or test string, including its capitalisation, spaces and punctuation.
2. Generate the bcrypt result.
3. Copy all 60 characters, including the opening version marker and cost.
4. Save the result in the password-hash column of your database.
5. During sign-in, use your platform's bcrypt verification function rather than generating a hash and comparing the text directly.

Bcrypt normally uses a new random salt for every hash. Hashing the same input twice can therefore produce two different records, both of which verify against that input. This is expected and prevents identical passwords from having identical stored values.

The work is done on the server. Your input travels to the server over HTTPS and is not stored. For a real production password, consider whether entering it into any third-party online service fits your organisation's security policy.

Can a bcrypt hash be decrypted or reversed?

No, a bcrypt hash cannot be decrypted because it is not encrypted data and contains no decryption key. The practical way to attack it is to guess possible passwords and verify each guess against the stored hash.

Bcrypt slows that guessing process through its configurable cost. It cannot make a short, common or previously leaked password safe, and a determined attacker may still find weak inputs. The salt stops attackers from reusing one precomputed table across many accounts, but the salt is not secret and is included in the stored record.

Reading a bcrypt result

A bcrypt result usually follows the modular crypt format. A representative shape is $2y$12$[22-character salt][31-character checksum]. This is a format illustration rather than the hash of a stated password.

Keep these parts together. Altering a character, trimming the value or storing it in a column that is too short will normally cause verification to fail. The version marker may differ between compatible libraries, so applications should rely on established password APIs rather than parsing and rebuilding the record themselves.

When should bcrypt be used?

Bcrypt should be used for password hashing in systems that already support it, particularly where compatibility with an existing database or framework matters. It is deliberately slow and salted, which makes it unsuitable as a general file checksum or deduplication identifier.

• Suitable uses include application passwords, migration testing, checking database field sizes and reproducing a bcrypt-compatible development environment.
• Use Argon2id instead for a new password system where the platform supports it and its memory settings can be managed properly.
• Use SHA-3 instead for file integrity, content fingerprints or deduplication. The SHA-3/384 generator and SHA-3/512 generator produce general-purpose digests, not password records.
• Do not use bcrypt for digital signatures, message authentication, encryption or storing data that must later be recovered.

Spaces, punctuation and numbers are processed as input data rather than ignored. Accented and non-Latin characters are encoded as bytes before bcrypt operates, so both systems must produce the same bytes, including by using consistent character encoding and Unicode normalisation. The 72-byte boundary is especially relevant here because a Unicode character can occupy more than one byte. Empty input can technically be hashed, but an empty password provides no meaningful resistance to guessing.

Frequently asked questions

How much database space does a bcrypt hash need?

Allow at least 60 ASCII characters for a conventional bcrypt record. A slightly wider field can help with future password-algorithm migrations, while a binary column is unnecessary for the standard encoded form.

Can I migrate existing SHA password hashes to bcrypt?

You cannot convert an existing SHA digest into the bcrypt hash of the original password without knowing that password. A common migration method verifies the old hash when the user next signs in, then hashes the supplied password with bcrypt or Argon2id and replaces the old record.

Before saving a result, check that the full 60-character value has been copied, the database field does not truncate it, and the receiving application supports the version marker in the record.