Skip to main content
AllDevToolsHub
Back to all patterns

US Social Security Number (SSN)

Validation

Validates US Social Security Numbers in the standard XXX-XX-XXXX format.

/^(?!000|666|9\d{2})\d{3}-(?!00)\d{2}-(?!0000)\d{4}$/

How it works

This pattern validates the SSN format and applies the SSA's known invalid number rules: area numbers 000, 666, and 900–999 are never assigned; group numbers 00 are invalid; serial numbers 0000 are invalid. Strip spaces before applying.

Test Cases

Should Match

  • 123-45-6789
  • 001-01-0001

Should NOT Match

  • 000-12-3456
  • 666-12-3456
  • 900-12-3456
  • 123-00-4567

Quick Summary

Validates US SSNs in XXX-XX-XXXX format. Applies SSA rules to reject known-invalid area numbers (000, 666, 900–999), group numbers (00), and serial numbers (0000). Handle SSNs as sensitive PII, never log or store unencrypted.

Key Takeaways

Key Takeaways

  • Format: three digits, dash, two digits, dash, four digits
  • Area number (first 3 digits) cannot be 000, 666, or 900–999
  • Group number (middle 2 digits) cannot be 00
  • Serial number (last 4 digits) cannot be 0000
Use Cases

When to use it

  • Validating SSN fields in government or financial applications
  • Detecting SSNs in text for PII redaction pipelines
  • Format checking before submitting to identity verification APIs
Watch out

Common Mistakes

  • Logging or storing SSNs in plaintext, always encrypt at rest
  • Using SSN as a unique identifier, use a separate internal ID instead
  • Not stripping dashes before comparing stored (unformatted) SSNs
FAQ

US Social Security Number (SSN), Frequently Asked

Are SSNs with dashes the only valid format?

The SSA uses the dashed format (XXX-XX-XXXX) officially. Some systems store them as 9 digits without dashes, validate both formats if needed.

How should I store SSNs?

Encrypt at rest using AES-256. Consider storing only the last 4 digits for display purposes and using a tokenization service for the full number.