🌳 Merkle Tree
Hash trees & proofs
root: 0000
8 leaves · depth 3
Data blocks (leaves)
Setup
Verify (Merkle proof)
Stats
Leaves
8
Tree levels
4
Proof size
—
Status
Ready
Info & Theory

A Merkle tree (hash tree) summarises many data blocks with a single hash, the Merkle root. Each leaf is the hash of a data block; each internal node is the hash of its two children concatenated.

How it is built

  • Hash every data block to form the leaf level.
  • Hash each adjacent pair together to form the parent level.
  • Repeat until a single node remains — the root. An odd node is duplicated (paired with itself).

Tamper evidence

Change one byte of one block and its leaf hash changes, which changes its parent, and so on up to the root. The root is a fingerprint of the entire dataset: any change is detectable from the root alone.

Merkle proof (inclusion proof)

To prove a block belongs under a known root you do not need all the data — only the sibling hash at each level on the path from the leaf to the root. That is just O(log n) hashes. The verifier rehashes upward and checks the result equals the trusted root.

Where it is used

Bitcoin and Ethereum block headers store a Merkle root so light clients can verify a transaction with a tiny proof. Git, IPFS, Certificate Transparency and many databases use the same idea for efficient, tamper-evident integrity checks.

About this simulation

For speed and clarity the hashes here use a small non-crypto mixing function (FNV-1a style) shown as short hex. Real systems use SHA-256 or Keccak, but the tree structure and proof logic are identical.

Frequently asked questions

What is a Merkle tree?

A Merkle tree is a binary tree of hashes. The leaves are hashes of data blocks and every parent is the hash of its two children, so a single root hash summarises all the data beneath it.

What is the Merkle root?

The Merkle root is the single hash at the top of the tree. It acts as a compact fingerprint of the entire dataset; if any block changes, the root changes too.

What is a Merkle proof?

A Merkle proof (or inclusion proof) is the set of sibling hashes along the path from a leaf to the root. With it you can prove a block belongs under a known root without revealing the other blocks.

Why does changing one leaf change the root?

Because each parent hash depends on its children, a change to one leaf cascades upward: its parent, grandparent and ultimately the root all change. This is what makes the tree tamper-evident.

How big is a Merkle proof?

A proof contains one sibling hash per tree level, so its size grows as O(log n) with the number of leaves n. For a million leaves that is only about twenty hashes.

Where are Merkle trees used?

They are used in Bitcoin and Ethereum block headers, Git commit history, IPFS, Certificate Transparency logs and many distributed databases for efficient integrity verification.

What happens with an odd number of leaves?

When a level has an odd number of nodes, the last node is paired with a copy of itself before hashing. This keeps the tree binary at every level.

Is the hash in this simulation cryptographically secure?

No. For speed the demo uses a small FNV-1a style mixing function shown as short hex. Real systems use SHA-256 or Keccak, but the tree structure and proof logic are exactly the same.

Can a Merkle proof verify a block is absent?

A standard Merkle proof shows inclusion. Proving absence requires a sorted variant such as a Merkle Patricia trie or a sparse Merkle tree, which this simulation does not cover.

How does a light client use the root?

A light client trusts only the small block header containing the root. To check a transaction it requests just the O(log n) sibling hashes, rehashes upward and compares against the trusted root.

About this simulation

Written by MySimulator Team · Reviewed by MySimulator Editorial Review

Last updated: 5 July 2026

This simulation builds a Merkle tree live in your browser: every data block becomes a leaf hash, adjacent hashes are paired and hashed again level by level, and the process repeats until a single Merkle root remains. Edit any block and watch the change ripple upward along the path to the root, or request a Merkle proof to verify one leaf belongs under that root using only O(log n) sibling hashes.

🔬 What it shows

The canvas draws every level of the tree from leaves at the bottom to the single root at the top, connecting each pair of children to their parent. Editing a data block box recomputes its leaf hash and highlights the changed path to the root in red, demonstrating that a Merkle tree is tamper-evident: no leaf can change without the root changing too.

🎮 How to use

Type into any Data blocks text field to change that leaf's content and watch the root hash update. Drag the Leaves slider (2–16) to resize the tree, then pick a Leaf index and click Verify leaf to build and highlight a Merkle proof: the sibling hash at each level (amber) plus the path to the root (purple), with the proof size shown in the Stats panel. Clear highlight resets the view.

💡 Did you know?

Bitcoin and Ethereum store a Merkle root in every block header so that a lightweight client can verify a single transaction is included in a multi-thousand-transaction block using only about twenty sibling hashes — a proof size that barely grows even if the block held a million transactions, since proof length scales as O(log n).

More questions about Merkle trees

Why does this simulation use a short FNV-1a hash instead of SHA-256?

The simulation swaps in a small, fast FNV-1a-style mixing function that produces a 4-hex-digit id instead of a full 256-bit SHA-256 digest, purely so the hashes are readable on screen and recompute instantly as you type. The tree-building algorithm, the tamper-evidence property, and the O(log n) proof logic are identical to production systems; only the underlying hash function differs.

What happens to the tree when the number of leaves is not a power of two?

At any level with an odd node count, the simulation's buildTree function pairs the last node with a copy of itself before hashing, which is exactly the duplicate-last-node rule used in real Merkle tree implementations such as Bitcoin's. This keeps every level binary so the tree always reduces cleanly to a single root, regardless of whether the leaf count (2 to 16 in this demo) is a power of two.

How is the changed path different from the proof path in the visualisation?

Editing a leaf triggers markChangedPath, which walks from that leaf up to the root marking every ancestor red to show which hashes were recomputed. Clicking Verify leaf instead triggers buildProof, which marks the path to the root in purple and marks the sibling hash needed at each level in amber — the minimal set of extra hashes a verifier needs to recompute the root from that one leaf, without seeing any other block.

Why is a Merkle proof only O(log n) hashes long?

Each level of the tree halves the number of nodes, so a tree of n leaves has about log2(n) levels. A proof needs exactly one sibling hash per level on the path from leaf to root, so its size grows logarithmically rather than linearly with the number of leaves — for a million leaves that is roughly 20 hashes, letting a light client verify inclusion without downloading the other 999,999 blocks.

Could two different leaves ever produce the same tree root?

In principle a hash collision could make two different datasets produce the same root, but with a cryptographically secure hash such as SHA-256 this is computationally infeasible — the demo's simplified FNV-1a-style function is not collision-resistant and is used here only for speed and readability, never for real integrity guarantees.