Hashing a customer list before sharing it feels like locking it. For long, random values it would be. For phone numbers it is more like writing the list in a code that every computer on earth can read - because the total number of possible phone numbers is tiny by computing standards. This page explains what hashed lists are genuinely for, and the limit nobody mentions.
There are honest reasons the bulk converter exists. Advertising platforms such as Meta and Google ask businesses to upload customer phone numbers and emails as SHA-256 hashes, so the platform can match them against its own hashed user list without either side exchanging raw numbers. Teams also hash lists to compare two databases, find overlaps and deduplicate, all without emailing raw personal data around. The matching works beautifully. What does not work is the assumption that the hashed list is now private or anonymous - and for phone numbers, it provably is not.
Hash matching depends on one property: the same input always gives the same hash. You hash your customer numbers; the platform hashes its users' numbers; identical numbers produce identical hashes on both sides, and those are the matches. Neither side had to show the other its raw list, and a person glancing at the file sees only 64-character strings. For comparison and matching, that is a real, legitimate benefit - and exactly the job the video's script is built for.
Notice what the benefit actually is: the raw numbers do not travel, and casual eyes cannot read the file. Both are about the journey and the glance. Neither says anything about what a determined holder of the file can do with it.
An Indian mobile number is 10 digits, and real ones start with 6, 7, 8 or 9. That leaves at most about four billion possible numbers - a big number for a human, and a tiny one for a computer. SHA-256 is deliberately fast: ordinary hardware hashes millions of values per second, and a single graphics card manages billions per second. Hashing every possible 10-digit number and building a lookup table is a coffee-break job, not a supercomputer project.
Once that table exists, every hash in your shared list resolves back to its phone number instantly. This is not a flaw in SHA-256 - the algorithm is doing its job perfectly. The flaw is in assuming a fingerprint of a guessable input keeps the input secret. It cannot.
Treat a hashed phone list almost exactly like the raw list. Store it in the same protected places, send it through the same approved channels, and share it with the same short list of people. The hash buys you three genuine things: the numbers are not readable at a glance or in a screenshot, the file is useless for casual misuse like copying numbers into a phone, and it satisfies the upload format that matching platforms require. Those are worth having. They are not anonymity.
Be especially careful with the verification habit from the video when real data is involved: pasting a customer's number into a random online hash checker hands that number to the site's owner, logged forever. Verify locally, as the verification page shows.
If two systems must match lists without either being reversible by outsiders, the standard answer is a keyed hash - HMAC-SHA-256 - or a hash with a secret salt that only the matching parties hold. The secret changes everything: an attacker with the file cannot brute force the number space, because they do not know the extra ingredient mixed into every hash. Both sides must use the identical secret and identical input formatting, or nothing matches.
And when there is no matching job at all - when the honest goal is simply that nobody should be able to recover the numbers - the answer is not to share the list, hashed or otherwise. Deleting data protects it better than disguising it.
The video shows the bulk conversion itself; this page is the privacy briefing to read before you share the output with anyone.
Watch Full VideoBecause the platforms never need to reverse anything - they hash their own users' numbers and match identical hashes. The format also stops raw numbers travelling through emails and dashboards. It is a matching format and a handling safeguard, not an anonymity tool.
No. Hashing the hash still leaves the same small set of possible starting numbers. An attacker hashes every number once, then hashes those results again, and the same lookup table works. Only a secret ingredient - a key or secret salt - changes the maths.
That depends on your purpose, your customers' consent and your local data protection law, which this page cannot judge. The technical point stands either way: do not describe or treat a hashed phone list as anonymised data, because technically it is not.