PBKDF2, or Password-Based Key Derivation Function 2, turns a password input and an additional parameter called salt into a derived key. The result also depends on the repetition count, calculation function and requested length. Identical inputs and settings produce the same result. BIP39 uses the specific PBKDF2-HMAC-SHA512 variant; other uses can choose different parameters.
The recovery words form the input named password. Salt is a second input: the literal text "mnemonic" followed by the passphrase, an optional additional password. No separator or second copy of the recovery words is inserted. Without a passphrase, salt remains "mnemonic", not an empty string. Both inputs undergo NFKD, which unifies certain character representations, and UTF-8 encoding. BIP39 uses HMAC-SHA512, 2048 repetitions and an output of 64 bytes, or 512 bits. That result is the seed; salt is not another backup you must create. [1]
Internally, HMAC combines a key with a message. The same password input remains the key in every round. The first intermediate result uses the salt and output block number; later rounds process the previous intermediate result. The results are combined with XOR, an operation on corresponding bits. HMAC-SHA512 returns 64 bytes, so BIP39 needs only one such block. Applying plain SHA-512 to text 2048 times would be a different calculation with a different result. [2] [1]
Imagine restoring into another wallet. To obtain the same seed, it needs the same normalized data and settings. Increasing the prescribed 2048 repetitions would not improve recovery: it would depart from BIP39 and produce a different result. Translating the recovery words into another wordlist is not neutral either. Recovery requires agreement, not a customized algorithm. [1]
Repeated calculations make each attempt more costly, but create no new independent randomness. An attacker who knows your words and has information that identifies the right wallet can try weak passphrases offline, on their own computer. A long 512-bit seed therefore does not imply 512 bits of unpredictability. Nor is 2048 a general recommendation for newly designed systems; here it belongs to a particular recovery standard. [2] [1]
The BIP39 checksum helps catch incorrectly copied words. PBKDF2 answers another question: how to calculate a seed from the supplied inputs. That calculation does not confirm that the passphrase belongs to your original wallet. The seed can then be processed by BIP32, a method for deriving a whole family of keys. Checking the record, converting it to a seed and creating keys are connected steps, but they are not interchangeable. [1]
A developer can compare results against public test vectors: known inputs with expected outputs. BIP39 publishes original random data, words and the entire seed for the test passphrase TREZOR. A correct implementation must reproduce the result, including the NFKD rules. Your real backup is unnecessary for this test. Never use the public examples for money, since everyone knows them. Passing a calculation test also does not establish the security of the whole application. [1]
For the clearest picture, read this entry together with BIP 39, BIP39 passphrase, Seed Generation, HD Wallet. The reverse links also lead from BIP39 passphrase.