How this calculation works
Each line becomes a leaf hash. Split a group at the largest power of two strictly smaller than its size, recursively hash the left and right subtrees, and combine their raw digest bytes. Preserve the original leaf order.
Leaf = SHA-256(0x00 || UTF-8 entry); parent = SHA-256(0x01 || left digest bytes || right digest bytes)A worked example
Four leaves form two pairs and one root. Proving Alice needs Bob’s leaf hash and the Carol–Dave subtree hash.
Good to know
This uses the RFC 9162 Merkle hash construction for text. It does not parse certificates or validate a live transparency log. It is not a Bitcoin block-root, Ethereum trie, or OpenZeppelin allowlist generator. Membership alone does not prove a record is true or that its root is trustworthy.
What a Merkle root commits to
A Merkle tree condenses an ordered list into one fixed-length fingerprint. Every entry first becomes a leaf digest; pairs of subtree digests then become parents until only the root remains. Changing a letter, rearranging two entries or inserting another record will normally change that root. The root is a commitment to the supplied bytes and their tree structure.
Enter one record per line and choose a leaf number. This calculator displays every leaf hash, the final root and the sibling hashes needed to connect your chosen entry to that root. No input is sent to our calculation server. The calculation code runs locally in your browser; the page may still load the website’s normal advertising resources.
The crypto wallet address format and checksum validator checks supported address encodings. A Merkle root commits to a list of records rather than validating wallet ownership.
The exact rules behind this calculator
This page follows the Merkle hash construction in RFC 9162. A text leaf is SHA-256 of the byte 0x00 followed by its UTF-8 bytes. A parent is SHA-256 of 0x01 followed by the 32 raw bytes of its left digest and the 32 raw bytes of its right digest. The prefixes distinguish leaf data from internal-node data.
For an uneven group, split at the largest power of two strictly below the group’s size. Three leaves become a two-leaf subtree plus one leaf. The last leaf is never duplicated. Order is preserved, and pairs are never sorted. These details are essential when comparing roots produced by different programs.
Verify one record without receiving the whole list
An inclusion proof supplies only the sibling subtrees needed along one path. With four leaves, proving the first entry needs its neighboring leaf hash and the hash of the other two-leaf subtree. The verifier starts with the entry’s prefixed leaf hash, places each sibling on its declared left or right side, and hashes upward.
Copy the generated JSON, choose Verify a proof, and enter the exact leaf text and expected root. A match means that this sequence of hashing steps reaches that root. This compact proof format establishes membership only; it does not separately certify a leaf position or the total tree size. A trusted root must come from an independent source, not from the same untrusted sender as the proof.
Try changing the data
Build the Alice, Bob, Carol and Dave example, then select a different leaf number. The root stays the same because the records have not changed; only the proof route changes. Next change Alice to alice. The leaf digest and every ancestor on that path change, while the Carol–Dave subtree remains unchanged. This isolates the difference between choosing a proof and changing the committed data.
Spaces are preserved, including leading and trailing spaces inside each line. CRLF line endings are treated as line separators just like LF. Empty lines, including an extra final newline, are rejected rather than silently removed. Unicode normalization is not applied: visually similar text can have different byte encodings and therefore different hashes.
Where the comparison stops
Bitcoin transaction trees, Ethereum state tries and smart-contract allowlists use their own encoding and hashing conventions. Selecting text that resembles a transaction ID does not make this calculator a Bitcoin block verifier. Likewise, SHA-256 output is not interchangeable with Ethereum’s Keccak-256, and a sorted-pair proof cannot be assumed to work here.
A root does not establish that an entry is honest, that a document is authorized, or that a transparency log has behaved consistently over time. This page does not validate signatures, log certificates, append-only consistency proofs or live blockchain records. Use it to learn the construction and compare compatible test data, with up to 128 leaves and 32,000 input characters.
A few questions, answered
Why is my Merkle root different from another tool?
Compare the hash algorithm, input encoding, leaf and parent prefixes, odd-leaf handling, leaf order and pair sorting. Every rule must agree.
Can one leaf have an empty proof?
Yes. A one-leaf tree has the leaf hash as its root, so its proof array is []. The verification text field requires a nonempty entry.
Does the proof hide my entry?
No. Verification requires the original entry, and hashing is not encryption. Predictable entries can be guessed. Use public test data rather than secrets.