Form fixture
- Input
- test form → required identifier field
- Expected output
- SSN → plausible synthetic value
Use it when a form needs to accept SSN without depending on real data.
SSN in privacy-first sandboxes
SSN in privacy-first sandboxes
This page focuses on using synthetic SSN in test scenarios. The goal is plausible data without touching real identifiers or implying official validation.
How to use synthetic SSN safely
- The tool generates synthetic SSN following 9 digits with SSA area, group and serial exclusions. That is enough for masks, fixtures and contract tests that depend on plausible format.
- SSN has no checksum; plausible format does not prove issuance, ownership, employment or credit eligibility.
- Use it for onboarding sandboxes, masks and tests that do not call real verification. Do not send the value to real verification, official registration, credit, employment, KYC or government services.
Useful test scenarios
Local rule test
- Input
- mask / prefix / check digit
- Expected output
- accepted locally → never treated as verified identity
The local rule covers 9 digits with SSA area, group and serial exclusions; it does not cover official lookup or registry existence.
Full tool FAQ
No. Common validation is based on structure and excluded ranges, not a checksum.
Frequently asked questions
Is synthetic SSN a real document?
No. It is a test value with plausible format or digits, without lookup in official databases.
What is the key limitation when using SSN in tests?
SSN has no checksum; plausible format does not prove issuance, ownership, employment or credit eligibility.
How can privacy risk be reduced?
Generate the value in the browser, do not store it in URLs or logs, and ensure analytics receives only action metadata, never the identifier.