Introduction
A Merkle proof lets you verify that a specific data item is part of a larger dataset without downloading the entire dataset. The prover sends the leaf hash, a list of sibling hashes (the proof), and the expected root hash. The verifier hashes the leaf with each sibling in sequence and checks whether the final hash equals the root. This tool does both sides: it builds a Merkle tree from leaf hashes and generates inclusion proofs, and it verifies proofs step by step, showing the computed hash at each level. All hashing uses SHA-256 and runs in your browser.
What this tool does
- Build a Merkle tree from a list of hex-encoded leaf hashes, displaying every layer from leaves to root with node counts
- Generate an inclusion proof for any leaf index, showing the sibling hashes and their positions (left or right) at each level
- Verify a Merkle proof by taking a leaf hash, a list of proof steps (L:hash or R:hash), and an expected root hash, then computing the hash chain step by step
- Show the computed hash after each proof step, so you can trace exactly how the leaf hash climbs to the root
- Handle Bitcoin-style trees where a node with no right sibling is duplicated (hashed with itself) to maintain the binary structure
- Run entirely client-side: all SHA-256 hashing is performed in your browser
How this tool works
The tool has two modes: Build Tree and Verify Proof. In Build Tree mode, you enter leaf hashes (one per line, hex-encoded). The tool constructs the tree bottom-up. It takes the leaf hashes as the bottom layer. For each subsequent layer, it pairs adjacent nodes from the layer below, concatenates their hashes (left bytes followed by right bytes), and computes SHA-256 of the concatenation. If a layer has an odd number of nodes, the last node is duplicated (its hash is concatenated with itself), which is the Bitcoin convention. This continues until a single node remains: the Merkle root.
The tool displays every layer with its node count and all hashes. You can select a leaf index, and the tool generates the inclusion proof for that leaf. The proof is a list of sibling hashes with their positions: L means the sibling is on the left (you hash sibling + current), R means the sibling is on the right (you hash current + sibling). The proof has one step per tree level above the leaves.
In Verify Proof mode, you enter a leaf hash, the expected root hash, and the proof steps (one per line in L:hash or R:hash format). The tool starts with the leaf hash as the current hash. For each proof step, it concatenates the current hash with the sibling hash in the correct order and computes SHA-256. The result becomes the new current hash for the next step. After all steps, it compares the final hash against the expected root. If they match, the proof is valid.
The tool shows the computed hash at each step, so you can see the hash chain building from leaf to root. If any step produces an unexpected hash, you can identify exactly where the proof breaks. All SHA-256 computation uses the Web Crypto API or a pure-TypeScript implementation, depending on the environment.
How Merkle trees and proofs work (Ralph Merkle 1979, RFC 6962)
Merkle trees were invented by Ralph Merkle in his 1979 paper A Certified Digital Signature, published at the CRYPTO 1989 conference. The core idea is to organize data into a binary tree of hashes where each non-leaf node is the hash of its two children. The root hash commits to the entire dataset: changing any leaf changes its hash, which propagates up the tree and changes the root.
An inclusion proof for a leaf requires only the sibling hashes along the path from the leaf to the root. For a tree with N leaves, the proof size is log2(N) hashes. A tree with 1 million leaves requires a proof of only 20 hashes, making verification extremely efficient compared to downloading all leaves.
Bitcoin uses Merkle trees to commit to all transactions in a block, as described in Section 4 of the Bitcoin Whitepaper. Each transaction is hashed with SHA-256 (actually double SHA-256 in Bitcoin, though this tool uses single SHA-256 for clarity). The block header contains the Merkle root. Lightweight clients (SPV nodes) can verify that a transaction is included in a block by requesting the Merkle proof from a full node, without downloading the entire block or the full blockchain.
Certificate Transparency, specified in RFC 6962, uses Merkle trees to build append-only logs of TLS certificates. When a certificate authority issues a certificate, it is appended to a Merkle tree. Anyone can verify inclusion of a specific certificate using a Merkle proof. The RFC defines the hash function as SHA-256 and the tree structure as a binary tree with leaf hashing (a domain separator prefix distinguishes leaf nodes from internal nodes).
This tool uses single SHA-256 for all internal nodes, matching the RFC 6962 approach. Bitcoin uses double SHA-256 (SHA-256 applied twice) for each node hash. The verification logic is identical in both cases; only the hash function differs. For Bitcoin-specific proof verification, apply SHA-256 twice at each step.
How to use this tool
- Choose a mode: Build Tree to construct a tree and generate proofs, or Verify Proof to check an existing proof
- In Build Tree mode, enter leaf hashes in the input field, one per line, as hex strings (64 characters for SHA-256 hashes)
- The tool displays the Merkle root, all tree layers with node counts, and the total number of layers
- Select a leaf index to generate its inclusion proof. The proof steps appear as L:hash or R:hash lines
- Copy the proof steps, leaf hash, and root hash. Switch to Verify Proof mode
- In Verify Proof mode, paste the leaf hash and root hash into their fields, and paste the proof steps into the input field
- The tool computes the hash chain step by step and reports whether the final hash matches the root. Review the step-by-step panel to trace each computation
Real-world examples
Building a tree from four transaction hashes
Input: four 64-character hex hashes (one per line). The tool builds three layers. Layer 0 has 4 leaves. Layer 1 has 2 nodes (SHA-256 of leaf0+leaf1 and SHA-256 of leaf2+leaf3). Layer 2 has 1 node: the root (SHA-256 of node0+node1 from layer 1). Selecting leaf index 1 generates a 2-step proof: the sibling of leaf 1 at layer 0 (leaf 0's hash, position L) and the sibling at layer 1 (the hash of leaf2+leaf3, position R).
Verifying an inclusion proof step by step
Leaf hash: `a1b2...`, root hash: `f0e1...`, proof: `L:c3d4...` then `R:e5f6...`. Step 1: the tool computes SHA-256(c3d4 + a1b2) because the sibling is on the left. Step 2: it computes SHA-256(result + e5f6) because the sibling is on the right. The final hash is compared against the root. If they match, the proof is valid and the leaf is confirmed as part of the tree.
Handling an odd number of leaves (Bitcoin-style duplication)
Input: three leaf hashes. Layer 0 has 3 leaves. Since 3 is odd, the third leaf is duplicated: node 2 at layer 1 is SHA-256(leaf2 + leaf2). Layer 1 now has 2 nodes, which pair normally into the root. This matches Bitcoin's block Merkle tree construction, where the last node is duplicated when a layer has an odd number of nodes.
Detecting a tampered proof
Take a valid proof and change one character in a sibling hash. The tool computes the hash chain with the corrupted sibling. At the step where the corrupted hash is used, the computed hash diverges from the expected value. All subsequent steps produce wrong hashes. The final hash does not match the root, and the tool reports 'PROOF INVALID.' This is how Merkle proofs detect tampering.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| Merkle inclusion proof | log2(N) hashes, SHA-256 per level | Bitcoin SPV, Certificate Transparency, airdrops |
| Full download verification | N hashes, all data | Full nodes, maximum trust assumptions |
| Merkle-Sum tree | log2(N) hashes plus range sums | Cryptocurrency exchanges, proof of reserves |
| Sparse Merkle tree | log2(N) hashes, supports non-inclusion | State trees in Ethereum, key-value stores |
| Verkle tree | log2(N) vector commitments | Ethereum state, future proof systems |
Limitations or considerations
This tool uses single SHA-256 for internal node hashing, following the RFC 6962 convention. Bitcoin uses double SHA-256 (SHA-256 applied twice) for each node. If you are verifying Bitcoin Merkle proofs, you must apply SHA-256 twice at each step. The tool's verification logic is correct for single-hash trees; for Bitcoin, use a Bitcoin-specific verifier or modify the hash function.
The tool does not implement sparse Merkle trees, which support non-inclusion proofs (proving that a key is NOT in the tree). Sparse Merkle trees use a different construction with default empty-node hashes. For state verification in Ethereum, sparse Merkle trees or Verkle trees are used.
The build mode accepts raw hex strings as leaves. In practice, leaves are typically SHA-256 hashes of actual data (transactions, certificates, file chunks). You must hash your data with SHA-256 first before entering the hashes as leaves. For SHA-256 hashing, see the SHA-256 Hash Generator.
The tool does not support Merkle-Sum trees or Verkle trees, which extend the basic Merkle construction with range sums or vector commitments. For interactive Merkle tree construction and visualization, see the Merkle Tree Calculator. For authenticated message authentication, see the HMAC Generator.
For Bitcoin address generation and validation, see the Bitcoin Address Generator.
Frequently asked questions
What is a Merkle proof and why is it useful?
A Merkle proof is a sequence of sibling hashes that lets you verify a leaf is part of a Merkle tree without downloading the entire tree. For a tree with N leaves, the proof contains log2(N) hashes. A tree with 1 million leaves needs only 20 hashes in the proof. This makes verification efficient for lightweight clients like Bitcoin SPV nodes.
Does this tool use single or double SHA-256?
This tool uses single SHA-256 for each internal node hash, following the RFC 6962 (Certificate Transparency) convention. Bitcoin uses double SHA-256 (SHA-256 applied twice) for Merkle tree nodes. If you are verifying Bitcoin block Merkle proofs, apply SHA-256 twice at each step instead of once.
What happens when a tree layer has an odd number of nodes?
The tool duplicates the last node, hashing it with itself. This is the Bitcoin convention: if a layer has 3 nodes, node 3 is paired with a copy of itself, producing SHA-256(node3 + node3). The next layer then has 2 nodes. RFC 6962 uses a different approach with domain-separated leaf and internal node hashing, but the duplication strategy is equivalent for binary trees.
How is this different from the Merkle Tree Calculator?
The Merkle Tree Calculator focuses on building trees and visualizing their structure. This tool adds proof generation and step-by-step proof verification. You can build a tree here, generate a proof for a specific leaf, copy the proof and root hash, then switch to verify mode to confirm the proof checks out. Both tools use SHA-256 for internal nodes.
Can Merkle proofs prove that a leaf is NOT in the tree?
Not with a standard Merkle tree. Standard inclusion proofs only prove presence. To prove absence, you need a sparse Merkle tree, which has a fixed position for every possible key and uses default hashes for empty positions. A non-inclusion proof shows that the position for a given key contains the default (empty) hash. This tool does not implement sparse Merkle trees.
Conclusion
Merkle proofs are the mechanism behind Bitcoin SPV verification, Certificate Transparency, and airdrop eligibility checks. This tool lets you build a tree, generate a proof, and verify it step by step, showing the hash computation at each level. For SHA-256 hashing of your data before building a tree, see the SHA-256 Hash Generator. For interactive tree construction, see the Merkle Tree Calculator. For authenticated hashing with a key, see the HMAC Generator. For Bitcoin address generation, see the Bitcoin Address Generator.