Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The same-looking email can produce two different SHA-256 hashes in conversion uploads because the upload paths may normalize the address differently before hashing. SHA-256 returns the same digest only when the exact input bytes match. For Google Ads enhanced conversions, Google specifies particular normalization rules—including extra transformations for Gmail and Googlemail addresses—but those rules are not universal email-canonicalization rules.
Why the hashes differ
A hash is calculated from bytes, not from what an address looks like on screen. Uppercase letters, surrounding whitespace, periods, plus suffixes, and text encoding can all affect the bytes supplied to SHA-256. If two upload paths transform the address differently, their digests can differ even when both implementations follow their respective instructions.
To diagnose a mismatch, compare the exact normalized input bytes first. Comparing only the original email strings or final digest strings does not reveal which step caused the difference.
Recommended Free Tools
Google Ads enhanced conversions: normalize by domain
For Google Ads enhanced conversions, Google’s API guidance says to remove leading and trailing whitespace and convert the email text to lowercase before applying SHA-256. It also specifies additional handling for addresses at gmail.com and googlemail.com: remove periods from the username and remove the plus sign and everything after it. Do not apply those extra transformations to other domains. Google’s online conversion upload documentation distinguishes these enhanced-conversion rules from Google’s treatment of email variations for Customer Match.
#1 Best Overall
Jane.Doe+Shopping@googlemail.combecomesjanedoe@googlemail.combefore hashing.user.name+NYC@example.combecomesuser.name+nyc@example.com; its period and plus suffix remain.
These are Google’s documented rules for this conversion workflow, not a general rule for email addresses or other platforms.
What to compare between two upload paths
Inspect each implementation against documentation for its specific destination, conversion product, and API version. A practical comparison should include:
- Destination and use case: identify the platform and whether the path is enhanced conversions, Customer Match, or another product.
- Normalization: check trimming, lowercasing, and any domain-specific changes to periods or plus suffixes.
- Encoding: establish the character encoding used to turn the normalized string into bytes.
- Fields and hashing: confirm which fields require SHA-256 and which must remain unhashed.
- Hash location and count: determine whether the value is hashed in the client or before upload, and verify that the implementation does not hash an already-hashed digest a second time.
These checks help isolate implementation differences; they do not imply that every listed failure occurred in a particular upload. Do not call a digest wrong until the expected normalization and the exact hash input have been compared.
Google’s other conversion-upload requirements
In the same Google Ads API guidance, Google lists email, phone number, first name, last name, and street address as data to hash with SHA-256. It says not to hash country, state, city, or ZIP code, and says phone numbers should use E.164 formatting. Keep those instructions within the relevant Google conversion-upload context rather than treating them as cross-platform rules. Google Ads API: Manage online click conversions
Google describes normalizing and hashing user-provided data, placing the resulting identifiers in conversion adjustment objects, uploading them through the appropriate service, and reviewing import diagnostics. Enhanced-conversion setup also requires accepting customer data terms, so confirm the account configuration as well as the code when investigating an upload problem.
Google’s official lead-upload code sample provides implementation examples for normalization and SHA-256. Use it as a reference for its particular version and workflow, not as proof that a separate production path has identical requirements.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Do not assume another platform uses Google’s email rules
An older “Conversions API Direct Integration Playbook” hosted on Google Cloud Storage describes SHA-256 hashing with UTF-8 encoding for customer-information parameters used in matching and distinguishes fields such as user agent that should not be hashed. That document does not establish Meta’s current email-specific normalization requirements. In particular, it is not evidence that Meta uses Google’s Gmail/Googlemail dot and plus-suffix transformations. Check the current official Meta documentation for the exact API and event type before relying on a cross-platform comparison.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
