Hash an email.
See what we'd store.
else.events keeps a SHA-256 hash of the recipient address in its delivery log — not the address itself. Paste an email below to see exactly which 64 hex characters would land in the log. The tool runs entirely in your browser; nothing is uploaded.
The hash is the index. The plaintext lives in your event payload.
When your app POSTs an event to /api/events, the payload carries the recipient address in plaintext. The renderer hands that address to your configured email provider (Postmark by default, SMTP optional) at send-time — that's the only moment we touch it.
What ends up in our delivery log (the table we query for activity, metrics, webhooks) is the SHA-256 hash you see above. Unsalted by design, so you can compute the same hash from your side and join it back to your own DB without us ever seeing a contact list.
When you open a delivery in the dashboard we re-resolve the address on request from the original event. Nothing is cached, nothing is aggregated — we don't keep a contact table to “sync”.
-
Why unsalted?
Salted hashes would mean we hold the salt and you don't — which puts us back in the business of being able to reverse the hash but you not being able to. The whole point is the opposite: you can compute the same hash, we cannot reverse ours.
-
Why lowercase + trim?
Email casing is officially case-insensitive on the local part for most providers, and casing varies by client. Lowercasing + trimming whitespace gives a stable hash for the same address, which is what you want when joining log entries back to your DB.
-
What this tool is not
It's not a checker, a reverser, or a privacy audit. It's a transparent demo of what we store. The math is the same SHA-256 every browser ships; the only thing else.events-specific is the lowercase-and-trim convention.
Want this in your stack?
POST events, we render and ship the email through your provider, the delivery log keeps only the hash. No contact list to sync, no audience export, no PII in the index we query.