# Salted vs Unsalted Hashes for Audience Uploads

> Security guides say always salt your hashes. Ad platforms can't match salted data. Both are right – here's the difference, and what it means for how you handle upload files.

- Source: https://www.8apps.co/blog/salted-vs-unsalted-hashes-audience-uploads
- Markdown: https://www.8apps.co/blog/salted-vs-unsalted-hashes-audience-uploads.md
- Published: 2026-09-02
- Author: 8apps Team
- Language: en

---
## Two rules that appear to contradict

Every security primer says: never store an unsalted hash. Every ad platform's upload flow implies: give us plain SHA-256 of the normalised value. A developer meeting audience uploads for the first time reasonably asks which rule is wrong. Neither is – they are solving opposite problems.

## What a salt is for

A salt is extra data mixed into the input before hashing, so that identical inputs produce different digests. That property is the whole point in credential storage: two users with the same password get different hashes, and precomputed lookup tables die. Salting is the standard because in that context, *unlinkability* is the goal.

## Why matching needs the opposite

Audience matching works precisely because identical inputs produce identical digests. You hash `john@example.com` your way; the platform hashes its own record of `john@example.com` the same way; the digests collide; that collision *is* the match. Introduce a salt only you know and your digests match nothing on Earth – a perfectly secure list of zero matched users. Deterministic, unsalted hashing is not a platform being lazy about security; it is the mechanism doing its job.

## The consequence you have to own

An unsalted digest of a small keyspace is weak by construction. Phone numbers especially: enumerate the national numbering plan, hash it all, and the "anonymised" column reads like plaintext to anyone with the table. This is not fixable – the weakness and the matching are the same property. So the handling rule follows: an upload file is *transport formatting*, not protection. Access-control it, share it deliberately, delete it when the campaign is done. (The longer argument is in our hashing-is-not-anonymisation guide.)

## Where each rule applies, in one table

| Context | Salt? | Why |
|---|---|---|
| Passwords, credentials | Always | Unlinkability; kill lookup tables |
| Ad-platform audience uploads | No | Matching requires deterministic digests |
| Internal pseudonymised analytics | Keyed/salted | You control both sides, so use a secret key |

The third row is worth the aside: when *you* are both hasher and matcher – joining datasets inside your own systems – there is no platform to match against, and a keyed hash gets you real protection. Reserve bare SHA-256 for the uploads that require it.

## Where Hash Data fits

[Hash Data](/google-workspace/hash-data) produces the standard digests audience uploads expect, inside Google Sheets – several algorithms as formulas, `=HASHPHONE()` normalising to E.164 and hashing in one step. What it cannot change is the physics above – which is why this page exists next to the product rather than pretending otherwise.

## Sources

- [EDPB Guidelines 01/2025 on Pseudonymisation](https://www.edpb.europa.eu/system/files/2025-01/edpb_guidelines_202501_pseudonymisation_en.pdf) – read 2026-08-20