Frequently Asked Questions

What is phone number hashing?

Phone number hashing converts a phone number into a fixed-length string (hash) using a one-way function like MD5, SHA-1, or SHA-256. The same number always produces the same hash, enabling matching and lookup without storing the raw number. See our what is phone hashing guide.

What is hash lookup?

Hash lookup is the process of querying a database or directory with a hash value to check if it exists, retrieve metadata, or correlate with other records. Our hash directory supports hash lookup for MD5, SHA-1, and SHA-256 phone hashes.

What is reverse hash lookup?

Reverse hash lookup recovers the original phone number from a hash. It is not mathematically possible from the hash alone—it requires pre-computed tables, brute-force over a known number space, or access to the system that produced the hash. Our reverse lookup service supports authorized reverse lookup. See our reverse hash lookup guide.

Which hash algorithm should I use?

For new systems, use SHA-256. It is collision-resistant and recommended by NIST. Use MD5 or SHA-1 only for legacy compatibility. See our MD5, SHA-1, and SHA-256 guides.

Why does my hash lookup fail?

Common causes: (1) Normalization mismatch—different systems hash different strings (e.g., +15551234567 vs. 5551234567). (2) Wrong algorithm—querying an MD5 hash against a SHA-256 index. (3) Format error—invalid hash format or length. See our debugging hashed phones guide.

What format should I use for hashing?

Use E.164: +[country code][subscriber number] with no spaces or punctuation. Example: +15551234567. Consistent format is critical—different formats produce different hashes. See our phone hash formats and international phone formatting.

Is hashing reversible?

Standard hashing is one-way—you cannot mathematically derive the input from the output. However, phone numbers have limited entropy, so attackers can use rainbow tables or brute-force to reverse hashes. For stronger protection, use salting or HMAC. See our privacy and security guide.

Is a hashed phone number personal data under GDPR?

Often yes. If the hash can be reversed or linked to an individual, it is personal data. Treat hashed phone numbers as personal data unless you can demonstrate effective anonymization. See our GDPR and phone data privacy guide.

How do I integrate the API?

Authenticate with an API key in the Authorization header. Use POST endpoints for lookup, reverse lookup, and phone-to-hash. See our developer API guide for endpoints, request/response formats, and rate limits.

Where can I perform hash lookup?

Use our hash directory for manual search. Use our reverse lookup for authorized reverse lookup. Use our phone-to-hash tool to convert numbers to hashes. For automation, use our API.

What are common use cases?

Marketing attribution, fraud detection, GDPR compliance, QA/testing, data deduplication, identity resolution, and threat intelligence. See our phone hash use cases guide. The common thread is correlating or verifying phone-based data without exposing raw PII. If your use case involves matching, blocking, or verifying phone numbers across systems, hashing may be appropriate. Evaluate whether you need the raw number for your use case—if you do (e.g., to send an SMS), hashing alone is insufficient. If you only need to check existence or correlate, hashing is often the right approach. Start with our what is phone hashing guide for an overview, then explore use-case-specific guides. Our developer API guide covers integration. For quick experimentation, use our web tools: hash directory, phone to hash, and reverse lookup. These tools require no account for basic use. For API access and reverse lookup, you'll need to sign up. We offer free tiers for development and low-volume production use. Enterprise tiers include higher rate limits, SLA guarantees, and dedicated support. See our pricing page for details. We're happy to discuss custom arrangements for high-volume or specialized use cases. Contact our sales team with your estimated volume, use case, and any special requirements (e.g., data residency, custom SLAs). We'll provide a quote and discuss options. For open-source projects and non-profits, we offer discounted or free access—apply through our website. We believe in supporting the developer and security community. Our documentation is free to use and reference. We welcome contributions, corrections, and feedback. If you find an error in our guides or have a suggestion for improvement, open an issue or submit a pull request on our GitHub repository. We review and respond to community input regularly.

How do I validate hashes before lookup?

Check length (32 for MD5, 40 for SHA-1, 64 for SHA-256) and character set (hexadecimal). Reject malformed input. See our hash validation best practices. Validation prevents wasted API calls and helps catch upstream bugs early. Implement validation at API boundaries and in batch processing pipelines.

Can I use phone hashes for authentication?

No. Hashes are deterministic—the same input always produces the same output. An attacker who obtains a hash can use it to match against future inputs. For authentication, use proper mechanisms (passwords with secure hashing and salting, OAuth, etc.). Phone hashes are for matching and correlation, not authentication.

What happens if I change my normalization?

Changing normalization changes all hashes. Existing lookups will fail because the hash values differ. If you must change normalization, plan a migration: dual-hash during transition, backfill from source data, and deprecate the old format. Communicate changes to integration partners well in advance.

Do you support SHA-512 or other algorithms?

We currently support MD5, SHA-1, and SHA-256. SHA-512 produces 128 hex characters; we may add support in the future for specialized use cases. For most applications, SHA-256 is sufficient. Contact us if you have a specific requirement.

How do I report a security issue?

We maintain a responsible disclosure program. Email security@phonehashing.com with details. Do not disclose vulnerabilities publicly before we have had a chance to address them. We acknowledge reports and work with researchers on fixes.

More Questions?

Explore our content index for in-depth guides. For technical support or partnership inquiries, see our contact page. For an overview of our service, see our about page.