PostgreSQL / MySQL / MariaDB Password Hashes
EncodingEverything runs locally in your browser — nothing is uploaded
Work out what actually sits in the password column of three databases. None of these schemes belongs in anything new — PostgreSQL's md5 does a single md5 with no iteration at all, and MySQL's `PASSWORD()` has been removed outright with its double SHA-1 long obsolete — but they still sit in countless `pg_authid` and `mysql.user` rows and in setup scripts everywhere. Moving a user between databases, or repairing one record by hand, means having to compute the value. The PostgreSQL case deserves particular care: it uses the username as the salt (hash = md5(password + username)), so the same password against a different username gives a completely different hash. Copy that hash under a new username and the login will simply fail.
Features
- Three dialects: PostgreSQL md5, and mysql_native_password for MySQL and MariaDB
- PostgreSQL computes over "password + username" — with an explanation of why the username matters
- Each dialect comes with a ready-to-run SQL statement (ALTER USER / SET PASSWORD)
- The hash and the SQL are separate rows, each with its own copy button
- Non-ASCII passwords are handled as UTF-8 bytes
- Computed locally; the password is never uploaded
How to use
- Choose the database
- Supply a username for PostgreSQL (it is used as the salt)
- Paste the password into the input box
- Copy the hash, or that SQL line
FAQ
- Why does PostgreSQL need the username?
- Because its `md5` scheme uses the username as the salt: `md5` + md5(password + username). The upside is not having to store a separate salt column; the cost is that renaming a role invalidates the password — move the hash under a different username and the inner md5 still carries the old name, so login fails. It is the most common trap when migrating users, which is why this tool says so on the page.
- MySQL removed PASSWORD() — is this still usable?
- MySQL 8.0 removed the `PASSWORD()` function, but the `mysql_native_password` plugin is still there (merely no longer the default, which is now `caching_sha2_password`). This tool computes exactly what that plugin expects: an asterisk followed by the uppercase hex of a double SHA-1. To set it for a MySQL 8.0 user, use `IDENTIFIED WITH mysql_native_password AS '…'` — which is the SQL this tool hands you.
- Are these schemes secure?
- No, and none of them belongs in anything new. PostgreSQL's md5 does one md5 with no iteration, and a modern GPU computes billions per second. MySQL's double SHA-1 adds a layer but is nowhere near the strength of a deliberate slow hash. The deeper problem is that neither salts properly (PostgreSQL's "salt" is the username — public and fixed), so rainbow tables apply directly. For new systems use bcrypt, scrypt or Argon2id — all three have tools on this site. This one exists for migration, not for new work.
Related tools
Bcrypt
EncodingGenerate bcrypt password hashes ($2y$ prefix) or verify a password against an existing one. The cost factor is adjustable; everything runs locally.
Scrypt
EncodingGenerate or verify scrypt password hashes in PHC format. Output as PHC, hex or Base64; hitting the memory ceiling warns, not silently lowering parameters.
Hash
EncodingCompute MD5, SHA-1, SHA-256, SHA-512 or MD4 digests of any text, hashed as UTF-8 bytes so they match openssl exactly. Runs in your browser.
Base64
EncodingConvert text to Base64 and back, with correct UTF-8 handling for accents, CJK and emoji. Runs entirely in your browser — nothing is uploaded.
URL Encode
EncodingEscape text into %XX form and back again, treating a whole URL and a single parameter value as different jobs. Runs entirely in your browser.
HTML Entities
EncodingTurn < > & and quotes into HTML entities and decode them back in a single pass, so &lt; becomes <, not an angle bracket. Runs in your browser.