Hashing and encryption solve different problems
A password hash is for checking, never for reading. An application stores the hash at sign-up and, at each login, hashes what the user typed and compares the two. If the database leaks, the attacker holds hashes and has to guess passwords one at a time. A good password hash is deliberately slow and salted, so each guess is expensive and identical passwords do not share a hash.
Encryption is for data you need back. The encryption tab takes text and a password and returns ciphertext that the same password turns back into the original. Use it to pass a note or a credential through a channel you do not trust, and send the password by a different route. Base64 and similar encodings are neither: they hide nothing.
Reading a bcrypt hash
A bcrypt hash is 60 characters long and, made here at the default cost, starts with $2b$12$. The 2b is the algorithm version and 12 is the cost factor. The next 22 characters are the salt and the last 31 are the hash itself. The cost is a power of two: cost 12 means 4,096 rounds of the key setup, and each step up doubles the work for you and for an attacker.
The slider runs from 8 to 15. Because the hash is computed in JavaScript, the top of the range takes the browser a while: cost 15 is eight times the work of cost 12. Choose the value for your server by timing a login there, not here. One limit to know: bcrypt reads only the first 72 bytes of the password, so longer input is cut off.
PBKDF2 and the plain SHA options
PBKDF2-SHA256 repeats HMAC-SHA-256 600,000 times over the password and a random salt, the iteration count that OWASP's password storage guidance gives for this algorithm. The output uses the layout pbkdf2_sha256$600000$salt$hash, the format Django stores in its user table. The iteration count is fixed on this page.
SHA-256, SHA-512 and SHA-1 return a single unsalted hex digest of the password. They are fast by design, which is the opposite of what password storage needs, and the page shows a warning when you select one. They are here for testing systems that still use them. MD5 is not offered. For an MD5 digest or a file checksum use the MD5 generator.
Verifying a password against an existing hash
The Verify panel works out the algorithm from the shape of the hash. A string beginning $2a$, $2b$ or $2y$ is treated as bcrypt, one beginning pbkdf2_sha256$ as PBKDF2, and a hex string of 40, 64 or 128 characters as SHA-1, SHA-256 or SHA-512. Anything else returns Unrecognised hash format. Hex digests are compared without regard to letter case.
This is a quick way to settle a login bug: take the hash from the database, type the password the user insists is right, and see whether the stored value can match. Formats outside that list, including Argon2, scrypt, salted SHA schemes and the $5$ and $6$ crypt formats, are not supported.
What the encrypted NDP1 string contains
Each encryption draws a random 16-byte salt and a random 12-byte nonce. The password and salt go through PBKDF2-SHA256 with 600,000 iterations to produce a 256-bit key, and AES-GCM encrypts the text with it. The output is the prefix NDP1, a dot, and the Base64 of salt, nonce, ciphertext and authentication tag joined together. Encrypting the same text twice gives different output.
The format belongs to this tool, so decrypt here. Other programs will not read it without code written for that layout. Security rests on the password: a short one can be guessed offline by anyone holding the string, however strong AES is. Build one with the random password generator. If the password is forgotten there is no recovery.