EIP-712
digests.

Types

All

atomic · dynamic · nested

Verified

Spec

matches the EIP-712 example

Network

None

keccak runs locally

Auth

None

no wallet, no signing

/29—EIP-712 HASH CALCULATOR

ready

▸ /notes

Why signing prompts became readable.

Before EIP-712, wallets showed an opaque hex blob and asked for a signature. Typed data lets the wallet render fields and values, and this page computes exactly what gets signed underneath that rendering.

Domain separation is the point.

The domain separator binds a signature to one contract on one chain, so a signature collected by one dapp cannot be replayed against another. If two implementations disagree, compare domain separators first; that is the most common mismatch.

Debugging a mismatch.

Work through the stages in order: encodeType string, then typeHash, then each struct hash, then the digest. The first stage that differs localizes the bug. All hashing is the same keccak-256 used across this site.

▸ /faq

What JSON shape does this expect?

The same object wallets receive for eth_signTypedData_v4: types (including EIP712Domain), primaryType, domain, and message. Load the built-in spec example to see the exact shape.

What is the 0x1901 prefix?

A domain separator marker from EIP-191: version byte 0x01 after 0x19 means "structured data". Hashing 0x1901 with the domain separator and message hash guarantees a signature for one dapp on one chain cannot be replayed against another.

Which types are supported?

The full EIP-712 set: atomic types (uintN, intN, address, bool, bytesN), dynamic string and bytes (hashed), fixed and dynamic arrays, and arbitrarily nested structs. Negative ints use two's complement, exactly as the spec requires.

How do I verify this tool is correct?

Load the spec example and compare: the domain separator ends in 912090f and the digest ends in 957bd2, matching the canonical values published with EIP-712. The whole computation also runs locally, so you can audit it in the page source.

EIP-712digests.