A block header is the small section of data at the start of every block in a blockchain that summarises the block and links it to the one before. In Bitcoin, the header is exactly 80 bytes long and contains six fields, including the hash of the previous block's header, a Merkle root that commits to all the transactions in the block, a timestamp and the nonce used in mining. The block's identity, its block hash, is the hash of this header.
Because each header contains the hash of the previous one, headers form an unbroken chain back to the genesis block. Changing any past transaction would change its block's Merkle root, its header and every header after it, which is why the structure makes history hard to rewrite. Headers are also what miners repeatedly hash in proof of work, and what lightweight wallets download to verify payments without storing the whole chain. Other blockchains use headers too, with different fields suited to their designs.
Block header in plain terms
Think of a set of sealed boxes stacked one on top of another. Each box has a label on the lid. The label says when the box was packed, gives a fingerprint of everything inside, and repeats the fingerprint of the label on the box below. If anyone opens a box lower down and swaps an item, its fingerprint changes, and every label above it stops matching.
A block header is that label. It is tiny compared with the box's contents, but it carries enough information to check that nothing inside has been tampered with and that the box sits in the right place in the stack. Anyone can check the labels quickly without unpacking every box.
Fields in a Bitcoin block header
| Field | Size | Purpose |
|---|---|---|
| Version | 4 bytes | Indicates which rules the block follows and signals support for upgrades |
| Previous block hash | 32 bytes | Links the block to the one before it |
| Merkle root | 32 bytes | A single hash summarising every transaction in the block |
| Timestamp | 4 bytes | Approximate time the block was created |
| Bits (target) | 4 bytes | Encodes the difficulty target the block hash must meet |
| Nonce | 4 bytes | A number miners change to search for a valid hash |
Bitcoin hashes the header twice with SHA-256 to produce the block hash. A block is valid only if that hash is numerically below the target encoded in the bits field.
Role in mining
Mining consists largely of hashing block headers over and over. A miner assembles a candidate block, computes its Merkle root and fills in the header, then tries nonce after nonce, hashing each version of the header to see whether the result meets the target. Because the nonce field is only 4 bytes, about four billion possibilities, modern miners exhaust it in a fraction of a second and also vary other data, such as an extra nonce in the first transaction, which changes the Merkle root. The difficulty target is adjusted every 2,016 blocks to keep the average block time near 10 minutes, as explained under mining difficulty. Since a miner only needs to hash the 80-byte header rather than the whole block, mining hardware can be highly specialised.
Headers and lightweight verification
The Bitcoin whitepaper described simplified payment verification, or SPV. A light client downloads only the chain of block headers, about 4 megabytes per 50,000 blocks, rather than every transaction. To check that a payment was included in a block, it asks a full node for a Merkle proof: the small set of hashes linking the transaction to the Merkle root in the header. If the proof matches and the header sits in the chain with the most work, the client can be confident the transaction was confirmed. Light clients trust that full nodes are enforcing the rules, so they offer weaker security than running a full node, but they make mobile wallets practical. Headers are also used by bridges and cross-chain systems that verify one chain's state from another.
Headers on other blockchains
Other networks include different fields. An Ethereum block header contains roots for the state, transactions and receipts, along with fields such as the gas limit, gas used and base fee, and since the move to proof of stake it no longer uses a mining nonce. Proof-of-stake chains include information about the proposer and validator signatures, while some chains add fields for data availability or rollup commitments. The common idea remains: the header commits to the block's contents and to its parent, making the chain tamper-evident. Explorers show header data for each block, along with its block height.