Page integrity snapshot.

01 / CURRENT ROOT

Merkle root.

Download the complete manifest

02 / CONSTRUCTION

Exactly how the tree is built.

1. Select every root-level *.html file except merkle.html.
2. Sort paths by their UTF-8 filename bytes.
3. Compute the visible canonical hash after replacing its own 64 hexadecimal characters with 64 ASCII zeroes.
4. Hash the exact served file with SHA-256.
5. Bind the filename and exact file digest into a domain-separated leaf.
6. Hash pairs of nodes with a different domain prefix. Duplicate the last node whenever a level has an odd count.

canonical_page_hash = SHA256(page_bytes_with_visible_hash_replaced_by_64_zeroes)
file_hash = SHA256(file_bytes)
leaf = SHA256(0x00 || uint32_be(len(path_utf8)) || path_utf8 || file_hash)
parent = SHA256(0x01 || left_hash || right_hash)

The visible value is canonical because embedding a file's exact hash inside that same file would change the file and therefore the hash. The exact served-file hash remains available in the manifest and is the value committed by the Merkle leaf. The generated page and JSON manifest are excluded from the tree to avoid self-reference.

03 / BLOCKCHAIN ANCHORING

What a blockchain can, and cannot, guarantee.

The Merkle root is a compact cryptographic commitment to the complete page set. If that 32-byte root is later included in a public blockchain transaction, the blockchain stores the commitment, not the pages themselves. Anyone holding a page and its inclusion proof can then demonstrate that the exact served-file hash belonged to the committed set no later than the anchoring block.

An anchor can make silent historical rewriting detectable because changing any committed byte produces a different page hash, leaf and root. It does not prove that a statement is true, identify who authored it, preserve the files by itself, or guarantee that the web server remains available. Those require separate signatures, trusted identity evidence and independent copies. A valid anchor must publish the blockchain, network, transaction ID, block height and anchored root so that the claim can be checked without trusting this server.

04 / PAGE SET

Committed pages.

05 / VERIFICATION

Verify independently.

Download a page and the JSON manifest. First verify the visible canonical hash by replacing the marked value with 64 ASCII zeroes before hashing. Then recompute the exact file and leaf hashes using the construction above and apply the proof steps in order. For a left step, hash the sibling before the current value; for a right step, hash it after the current value. The final digest must equal the published root.

The manifest clearly distinguishes canonical_sha256 from file_sha256 and explicitly reports whether a blockchain anchor exists. It is designed for offline verification and contains no secret material, signatures, analytics or visitor-specific data.

• Merkle manifestMachine-readable root, algorithms, page records and inclusion proofs.
• Resources indexReturn to the public documentation and network resources.