Skip to content

Bcrypt hashes Laravel will accept

Set to the $2y$ prefix and cost 12 that Laravel expects. Change either one if your project has been configured differently. Nothing you type here leaves the browser.

Everything below this line runs locally

0/72 bytes · 4,096 iterations · 0 network requests

Laravel hashes with bcrypt at cost 12 by default, configured in config/hashing.php. Older releases shipped cost 10, so check the config before you assume.

The same thing in Laravel

Hashing in Laravel

use Illuminate\Support\Facades\Hash;

$hash = Hash::make('correct horse battery staple');

Checking a password

if (Hash::check($request->password, $user->password)) {
    // the password matched
}

From a terminal

php artisan tinker
>>> Hash::make('correct horse battery staple')

Check a hash from your database

Paste a stored hash and a candidate password to confirm they match, which is a quick way to rule the hash out when a login is failing for reasons you cannot see.

Verification also runs locally

Other stacks

Questions people ask

Which prefix does Laravel write?
$2y$. The tool on this page is set to that by default. For any password under 72 bytes the digest is identical across $2a, $2b and $2y, so the prefix is a label rather than a different algorithm, and most libraries verify all three regardless of which one they produce. PHP is the exception: password_verify accepts all three, but password_get_info reports bcrypt only for $2y, and Laravel Hash::check asks that question before it compares, so a $2a or $2b hash is refused there with "This password does not use the Bcrypt algorithm".
What cost does Laravel use by default?
Laravel hashes with bcrypt at cost 12 by default, configured in config/hashing.php. Older releases shipped cost 10, so check the config before you assume.
Can I paste this hash straight into my database?
Yes. A bcrypt hash is 60 characters and carries its own version, cost and salt, so the column needs no companion fields. Check the column is at least 60 characters wide, because a narrower one will truncate and lock the account out.
Is it safe to generate a production password here?
The hashing runs in your browser and this page makes no network request when you press the button. For a seed account or a test fixture that is fine. For a real user credential, the better habit is to let your own application hash it.
Why does my Laravel login reject a hash that looks correct?
Usually one of four things: a prefix the framework will not accept, which on PHP and Laravel means anything other than $2y$, a trailing newline picked up during copy and paste, a column too narrow to hold all 60 characters, or a password longer than 72 bytes where the two sides truncated it differently.

Next