# MD5, SHA-1 or SHA-256 for Customer Data?

> The tool offers five algorithms; the upload needs exactly one. What Google, Meta and TikTok actually accept, how to recognise each digest on sight, and the one-line rule.

- Source: https://www.8apps.co/blog/md5-sha1-sha256-customer-data
- Markdown: https://www.8apps.co/blog/md5-sha1-sha256-customer-data.md
- Published: 2026-09-02
- Author: 8apps Team
- Language: en

---
## The one-line rule

Use SHA-256, hex, lowercase, unless the destination's documentation says otherwise in writing. Everything below is the reasoning and the exceptions.

## What the platforms document

- **Google Ads:** *"Use hex SHA256"* – its customer-data formatting page names SHA-256 and hex encoding.
- **Meta:** SHA-256 digests, hex with lowercase letters – its docs specify *"HEX representations… using lowercase for A through F"*, and its published test vector is a SHA-256 digest.
- **TikTok:** the outlier that documents a choice – *"MD5 and SHA256 encryption is supported"*, with the file's content *"in all uppercase or lowercase"* before encryption. It also accepts unhashed values and hashes them for you.

Nobody documents SHA-1 for customer uploads; nobody requires anything stronger than SHA-256.

## Why SHA-256 won

MD5 (1992) and SHA-1 (1995) are cryptographically broken for collision resistance – both retired from security use across the industry years ago. For upload matching, the platforms' preference does the deciding anyway: SHA-256 is what the docs name, so SHA-256 is what matches. TikTok's MD5 support is best read as legacy accommodation – supported is not recommended, and a SHA-256 column serves TikTok while remaining reusable logic for the other two.

## Recognise a digest on sight

Hex digest length is fixed per algorithm, which makes a spreadsheet column self-identifying:

| Algorithm | Hex length | Looks like |
|---|---|---|
| MD5 | 32 chars | `9e107d9d372bb682…` |
| SHA-1 | 40 chars | `2fd4e1c67a2d28fc…` |
| SHA-256 | 64 chars | `62a14e44f765419d…` |

`=LEN(B2)` down the column tells you what a mystery file holds – 32 means someone hashed with MD5, 64 with SHA-256, 128 means a digest was hashed *again*. This is the fastest audit there is of an inherited "already hashed" list.

## The part the algorithm cannot fix

A perfect SHA-256 of a badly normalised input matches nothing. Casing, whitespace, phone formats that differ per platform – normalisation decides the match rate; the algorithm just has to be the one the destination expects. The normalisation rules live in our email and phone hashing guides; pick the algorithm here, then do the real work there.

## Where Hash Data fits

[Hash Data](/google-workspace/hash-data) offers multiple hash algorithms as Google Sheets formulas – so when one destination wants SHA-256 and a legacy system still asks for MD5, both are a fill-down in the same sheet, next to the normalisation formulas that actually decide whether anything matches.

## Sources

- [Google Ads Help – Format your customer data file](https://support.google.com/google-ads/answer/7659867) – read 2026-08-20
- [Meta – Conversions API customer information parameters](https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters/) – read 2026-08-20
- [TikTok – About guidelines for customer files](https://ads.tiktok.com/help/article/customer-file-faq) – read 2026-08-20