Aadvanced matching with pre-hashed PII – clarification on Meta’s expectations

Hi everyone 👋

I’m working on a browser-only setup for conversion tracking and I’d like to double-check a few details specifically on the Meta side (naming, hashing detection, and what the Pixel actually expects).

Context

• the lead/conversion event fires on a thank-you page
• the user data (email, phone, name…) is collected on the previous page
• I can’t fire the event on the form page as the tracking wouldn't be always truthful
• I don’t have a server / CAPI in this flow, so this is 100% client-side

To bridge the two pages, I’m doing this:

1. on the form page I collect the user fields
2. I normalize them in two ways (Google-style and Meta-style)
3. I hash the Meta-normalized version with SHA-256
4. I temporarily store it in sessionStorage
5. on the thank-you page I read it and want to send it with the Meta Pixel event

So far, so good.

What I’d like to confirm 👇

1. Does the Pixel reliably accept SHA-256 hashed customer data sent via fbq('track', 'Lead', ..., { …customer data… })? In other words: if I send the customer info already hashed, Meta will still match it, right?
2. Do I need to tell Meta explicitly that the values are already hashed (like a flag or a specific param), or will the Pixel detect it automatically from the format? I know Google makes you use different parameter names for hashed values – I couldn’t find something equally explicit for Meta.
3. What’s the most “standard” way to send hashed user data client-side right now?
   - plain fbq('track', ...) with customer data object
   - GTM template (e.g. facebookarchive or Stape style?)
   - other approach you’ve seen working better in production
   I’m trying to avoid situations where the template re-hashes what I already hashed and we end up with double-hash and no matching.
   - In your experience, do current Meta templates auto-hash by default? If yes, is there a clean way to say “I’m already sending hashed values, please don’t touch them”?

I’m aware that server-side CAPI would make all of this nicer, but in this scenario I need to stay client-only and make sure I’m not breaking matching just because the actual event is on a different page.

Any real-world examples/snippets from would be super helpful 🙏