Merkle Tree Generator
Build a Merkle tree from a list of leaves and compute its Merkle root using SHA-256, SHA-1 or Keccak-256. Choose UTF-8 or hex leaf encoding, the Bitcoin duplicate-last or promote odd-node rule, and raw or OpenZeppelin sorted pair concatenation.
Input
How each line is interpreted before hashing.
What to do when a level has an odd number of nodes.
How left and right child hashes are combined before re-hashing.
Output
The single fingerprint of the whole leaf set — changing any leaf changes the root.
Tree nodes (leaves → root)
| Node | Leaf / input | Hash (hex) |
|---|---|---|
| No data yet | ||
Guides
Paste a list of leaves — one per line — and this tool builds a Merkle tree and computes its Merkle root: a single hash that fingerprints the entire set. Change any leaf, add one, or reorder them, and the root changes completely. Everything runs locally in your browser; the leaves you enter are never uploaded.
What is a Merkle tree?
A Merkle tree (or hash tree) is a binary tree of hashes. The bottom row — the leaves — holds the hash of each piece of data. Every level above is built by taking adjacent nodes in pairs, concatenating their hashes, and hashing the result to produce a parent node. This repeats until a single node remains at the top: the Merkle root.
Because each parent hash depends on both of its children, the root depends — transitively — on every leaf. That is what makes the root a compact, tamper-evident summary of the whole data set.
Why Merkle roots matter for blockchains
Merkle trees are the backbone of blockchain verification:
- Bitcoin stores only the Merkle root of a block's transactions in the block header. The root commits to every transaction without the header carrying them all.
- Ethereum uses Merkle-Patricia tries (built on Keccak-256) to commit to account state, transactions, and receipts.
- Merkle proofs let a light client verify that one specific leaf belongs to a tree by supplying only the sibling hashes along the path to the root —
log₂(n)hashes instead of the full data set. This powers airdrop allowlists, SPV wallets, rollup state proofs, and certificate transparency logs.
Options
- Hash function — SHA-256 (Bitcoin), SHA-1, or Keccak-256 (Ethereum's original Keccak padding, not FIPS-202 SHA3-256; the two produce different digests).
- Leaf encoding — treat each line as UTF-8 text (it is hashed first), or as hex bytes that are already hashed (used unchanged as the leaf).
- Odd-leaf rule — when a level has an odd number of nodes, either duplicate the last node (Bitcoin's convention) or promote it (carry the unpaired node up to the next level untouched). The two rules produce different roots.
- Pair concatenation — combine each pair as raw concatenated bytes (the standard order-preserving convention), or as sorted bytes (OpenZeppelin's
MerkleProof, where the two child hashes are ordered before concatenation so proofs don't need to encode left/right position).
The output shows the Merkle root plus a table of every node in the tree, from the leaves up to the root, with each node's hash in hex.
Does leaf order matter?
Yes — with raw-byte concatenation, swapping two leaves changes the root. With the sorted-pairs (OpenZeppelin) option, the order within each pair is normalized, which is why that scheme is convenient for proofs, but the overall set and pairing still determine the root.
Why does my root not match another tool's?
Merkle roots are only comparable when every convention matches: the same hash function, the same leaf encoding, the same odd-node rule, and the same concatenation order (raw vs sorted). A mismatch in any one of these yields a completely different root. Match the settings to the system you are verifying against.