How to hash emails and phone numbers for Enhanced Conversions, Customer Match, and Meta CAPI

Every hashed-identifier upload API — Google Ads Customer Match, Enhanced Conversions, GA4 user-provided data, Meta’s Conversions API — accepts a SHA-256 hex digest and matches it against the platform’s own hashes of known users. The failure mode is silent: a wrongly normalized value hashes fine and uploads fine, it just never matches anything. Hash [email protected] without lowercasing it first and Google reports a successful upload with a quietly terrible match rate. Nobody throws an error, because a hash of the wrong string is still a perfectly valid hash.

The PII Hasher is a free tool that encodes each platform’s published normalization rules — which differ in ways that matter — and shows you exactly which transformations were applied to your input before the hash was computed. It runs entirely in your browser via the Web Crypto API: the page makes zero network requests, works offline, and your data never leaves your machine.

What it does

You pick a platform, type or paste an email or phone number, and the tool shows three things: the normalization steps applied to your input (each marked as changed, already-OK, off for this platform, warning, failed, or skipped), the exact normalized string that gets hashed, and the SHA-256 digest as lowercase hex. Three platform profiles are built in:

• Google — Customer Match, Enhanced Conversions, and GA4 user-provided data, which follow the same Google rules. Emails are trimmed and lowercased, and dots in the local part of @gmail.com / @googlemail.com addresses are removed. Phones are hashed in E.164 form with the leading + (e.g. +14155550132).
• Meta — Conversions API and pixel Advanced Matching. Emails are trimmed and lowercased only; Meta has no gmail-dot rule. Phones are hashed as digits only — country code included, no +, no punctuation (e.g. 14155550132).
• Generic — a canonical default (trim + lowercase email, E.164 with + for phones) for systems without a published spec. The tool is explicit that this is a sensible default, not a vendor requirement.

These differences are why cross-platform hash reuse fails: [email protected] and [email protected] produce the same hash for Google and different hashes for Meta, and the same phone number hashes differently on Google (with +) than on Meta (without). The tool’s reference tables spell out each rule per platform, and the step list flags cases like “Meta keeps the dots — this hash will differ from the Google hash of the same address.”

A batch mode handles lists: one value per line, auto-detected type per line, with a results table and CSV export.

How it works

The engine is a small dependency-free script (pii.js) you can read in full — every rule below is literally in the code.

Type detection. A value containing @ is treated as an email. A value containing at least one digit and consisting only of digits, +, spaces, dots, slashes, parentheses, and dash-like characters is treated as a phone number. Anything else is rejected with a prompt to pick the type explicitly rather than guessed at.

Email pipeline. Trim, then lowercase, then a shape check: exactly one @, no interior whitespace, a non-empty local part and domain. A domain with no dot produces a warning (most platforms reject such addresses) but still hashes. Only then does the platform-conditional rule run: on Google, dots are removed from the local part when the domain is exactly gmail.com or googlemail.com; on Meta and Generic the step is shown as “off” so you can see the divergence rather than wonder about it.

Phone pipeline. Every non-digit character is stripped (letters trigger a warning that vanity numbers must be converted to digits first). The result is then checked against E.164 shape: a leading 0 after stripping is a hard error, because E.164 country codes never start with 0 — the error message tells you to drop the national trunk prefix and add the country code (UK 020 7946 0958 → +44 20 7946 0958). Fewer than 7 digits fails as too short for a country code plus subscriber number (7, not more, because a handful of small numbering plans issue valid 7-digit totals); more than 15 digits fails because E.164 allows at most 15. If the input had no leading +, the tool can’t verify a country code is present, so it warns instead of guessing: a national number without its country code hashes fine but will never match. Finally the platform prefix rule applies — + prepended for Google and Generic, digits only for Meta.

Hashing. The normalized string is UTF-8 encoded with TextEncoder and digested with crypto.subtle.digest("SHA-256", …) — the browser’s native Web Crypto implementation, not a JavaScript polyfill. The output is the standard 64-character lowercase hex form all of these platforms expect. Because crypto.subtle only exists in secure contexts, the page tells you up front if you’ve opened it in a context where hashing can’t run.

CSV export. Batch results export with \r\n line endings and proper quoting, and every cell that starts with =, +, -, @, a tab, or a carriage return is prefixed with a single quote so a hostile pasted value (e.g. =HYPERLINK(...)) can’t execute as a spreadsheet formula when you open the file in Excel or Sheets.

How to use it

1. Open the PII Hasher and choose a platform: Google, Meta, or Generic. A note under the selector summarizes that platform’s email and phone rules.
2. Single value: type an email or phone into the input. Type is auto-detected (you can force Email or Phone in the dropdown). The step list, normalized value, and hash update live on every keystroke; the normalized value and the hash each have a copy button.
3. Batch: switch to the “Batch — one per line” tab, paste your list, and click “Normalize + hash” (or press Ctrl/Cmd+Enter). The “Sample data” button loads a demonstration set — gmail addresses with dots and stray capitalization, a US number with punctuation, a UK number with and without its country code — that exercises most of the rules at once.
4. Read the results table: line number, detected type, original, normalized value, hash, and notes. Lines that fail validation are flagged in red instead of hashed; warnings show in amber. Switching platforms re-runs the batch so you never look at stale hashes.
5. Click “Download CSV” to export. By default the CSV contains only line number, type, hash, and note. A checkbox adds the original and normalized values — and triggers an explicit warning that the file will then contain raw, un-hashed PII and should be treated accordingly.

Limitations

• Shape validation, not verification. The email check is structural (one @, non-empty parts, no whitespace), not full RFC parsing or deliverability testing. The phone check validates E.164 shape only — it cannot confirm that a number without a leading + actually includes its country code, which is why that case warns rather than passes silently.
• Emails and phones only. Platforms also accept hashed names, postal addresses, and zip codes with their own normalization rules; this tool doesn’t cover those fields.
• Generic mode is a default, not a spec. For any destination other than Google or Meta, verify the destination system’s own rules before shipping hashes.
• Display cap in batch mode. The results table renders the first 500 rows; the CSV export always contains all of them.
• Hashing is pseudonymization, not anonymization. As the tool itself states: under GDPR and most privacy laws, a SHA-256 hash of an email or phone number is still personal data. Hashing formats identifiers for matching APIs — it does not remove your consent or data-protection obligations, and exports should be handled as personal data.

FAQ

Why does the same email produce different hashes on Google and Meta? Google removes dots from the local part of gmail addresses before hashing; Meta keeps them. So [email protected] and [email protected] collapse to one hash for Google but stay two distinct hashes for Meta. Any other difference in normalization (case, whitespace) has the same effect, which is why the tool shows the exact string being hashed.

Do I include the + when hashing phone numbers? For Google (Customer Match, Enhanced Conversions, GA4 user-provided data): yes — hash the E.164 string including the +, e.g. +14155550132. For Meta CAPI: no — hash digits only, 14155550132. Sending one platform’s phone hash to the other never matches.

Is my customer data uploaded anywhere when I use this tool? No. Normalization and hashing run locally in your browser via the Web Crypto API, and the page makes no network requests — it works offline. The only file that ever exists is the CSV you explicitly download to your own machine.

Why does my phone number fail with “starts with 0”? You’ve included a national trunk prefix (like the leading 0 in UK 020 7946 0958) or a 00 dialling prefix. E.164 country codes never start with 0 — drop the trunk prefix and add the country code: +44 20 7946 0958.

Does hashing make the data anonymous for GDPR purposes? No. A hashed email is pseudonymous: anyone with the same email can recompute the hash and link it back. Regulators treat hashed identifiers as personal data, so consent and processing rules still apply to hashed uploads.

Related

• PII Hasher — the tool itself; free, client-side, no signup.
• Server-side tracking — where hashed-identifier uploads usually live in production: Conversions API calls and enhanced conversions sent from infrastructure you control rather than the browser.
• GA4 guide — user-provided data collection is the GA4 feature that consumes Google-normalized hashes.
• Beacon Decoder — inspect what your tags actually transmit, including whether user data parameters are present and hashed.
• How web tracking works — the wider context for identifiers, matching, and beacons.
• GPC and consent — hashed identifiers are still personal data, so consent signals govern these uploads too.
• All free tools — the rest of the webtracking.org toolbox.