Previous block header hash

Each block points backwards, never forwards. Because the pointer sits inside the 80 bytes that get hashed, editing anything in an old block changes its hash and breaks every block built on top of it, so undoing a payment from a year ago means redoing roughly 52,000 blocks of proof of work. That, and not any rule about deleting data, is what people mean when they call bitcoin immutable.

How it works

The previous block header hash is produced by running SHA-256 twice over the parent's 80 byte header, and it is the only reference a block keeps to anything outside itself.

Because the parent's header contains its own parent's hash, and so on back to the beginning, one 32 byte field commits to the entire history behind it. A node that has verified the tip has implicitly verified that the chain leading to it is internally consistent. Tamper with a transaction in a block mined last summer and that block's header hash changes, which means the child's copy of it no longer matches, which means the child is invalid, and so is everything after. Repairing the damage means re-mining every one of those blocks, at roughly 144 blocks a day, or 52,560 a year.

The genesis block is the exception, and it has to be: there is nothing before it, so the field is 32 zero bytes.

Nothing in a block points forward. When Bitcoin Core reports a nextblockhash it is reading its own index, not the block, which is exactly why the value can change during a reorganization while the previous block header hash never does. Two blocks naming the same parent is not an error either. That is what a fork looks like from the data's point of view, and the network resolves it by preferring the branch with the most accumulated work rather than by declaring either pointer wrong.

Where you see it

The previous block header hash surfaces under slightly different names depending on what you are looking at.

Bitcoin Core returns it as previousblockhash from getblockheader and getblock. For block 0 the field is simply absent from the response, because there is no parent to name. Block explorers usually label it Previous Block and turn it into a link, which is how clicking backwards through history works.

It is also the whole substance of a header chain sync. A node downloading headers is checking two things per header: that this one names the last one, and that its hash meets the target. Only after that chain holds together does it start asking for block bodies. Lightweight wallets never go further than this, keeping the links and the work and nothing else.

If you ever build the field by hand, expect an argument with your own eyes, because the bytes in the header are not written in the order the hash is normally quoted.

Previous block header hash vs internal byte order

The previous block header hash is stored in the opposite byte order to the one everybody quotes, and that trips up nearly everyone who tries to verify a header manually. Block 1 carries its parent's hash as 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000. That is the genesis hash, 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, written backwards one byte at a time. The leading zeros that proof of work produces end up trailing in the raw field. Nothing is wrong when the two do not visibly match: reverse the bytes and they do.