Web3/Blockchain

EIP-712 Typed Data Hasher

Compute the EIP-712 domain separator, type hash and final signing digest for typed data, so you can verify what a wallet is actually asking you to sign.

Last reviewed by the Radiatus Cloud team

Results appear here.

Need this done properly for your business?

Radiatus delivers secure cloud, DevOps & compliance engineering.

Book a free consult

EIP-712 exists so that a signature request is readable

Signing an opaque hash means approving something you cannot inspect, which is why blind signing is dangerous. EIP-712 structures the data so a wallet can display the actual fields, and it binds the signature to a domain: a name, a version, a chain and a verifying contract. That binding is what stops a signature gathered for one application from being replayed against another, and it is the part that is invisible in the displayed message while doing most of the security work.

The type hash is a commitment to the shape of the data

The encoded type string lists every field name and type in order, and its keccak hash becomes part of the struct hash. Change a field name, reorder the fields, or alter a type, and the hash changes entirely, so a signature over one structure cannot be reinterpreted as a signature over another. This is why the type string has to match exactly between the signer and the verifying contract, and why an apparently cosmetic rename breaks every previously issued signature.

The digest is what is actually signed

The final value is the keccak hash of the two magic bytes 0x1901, the domain separator, and the struct hash. Everything the wallet shows is an interpretation of the inputs to that; the signature covers the digest alone. Recomputing it independently is the only way to confirm that what you are being shown corresponds to what you would be signing, which matters most in exactly the cases where a site has a reason to misrepresent it.

Related tools

Frequently Asked Questions

Why does EIP-712 have a domain separator?

To bind the signature to a specific application, version, chain and contract, so a signature gathered for one cannot be replayed against another. It does most of the security work and is invisible in the displayed message.

What is the type hash?

The keccak hash of the encoded type string, which lists every field name and type in order. It commits the signature to the exact shape of the data, so a rename or reorder invalidates every previously issued signature.

Why do the magic bytes 0x1901 appear?

They prefix the digest so that a typed-data signature can never be mistaken for a transaction signature or a personal-message signature. Domain separation between signature kinds is the point.

Should I ever sign something I cannot read?

No. Blind signing is approving a payload the device cannot decode, and EIP-712 exists precisely so that it is not necessary.

Does a valid digest mean the request is safe?

No. It means the displayed fields match what is being signed. Whether granting that permission is wise is a separate question, and an unlimited Permit to an unknown spender is a valid signature over a dangerous request.

Privacy & Security

Everything runs in your browser; nothing is uploaded.

Data: None
Client-side-Side
Active
v1.0

How to Use

Enter your domain and message type to compute the signing digest.

Disclaimer: This tool is provided "as is" without warranty of any kind. Results are for educational and utility purposes.