SSN Generator

Continue in the tool

More pages for this tool

SSN in privacy-first sandboxes

Synthetic SSN in privacy-first sandboxes

The SSN is not just another field: on its own, it already identifies a person in the United States, with no name or address attached. This page covers why that matters in any test environment.

Why a staging dump can never hold a real SSN

In the United States the SSN is used to open credit, hire an employee and file taxes, which makes it a direct identifier: on its own it already points at one specific person, unlike a field such as birth city, which only identifies someone when combined with other data. A staging database dump with even a single real SSN turns an internal leak into a reportable incident, so the test environment must hold only a synthetic value.
Between 1938 and the 1970s a wallet manufacturer printed, as a sample insert inside every new wallet, a Social Security card carrying a real employee's number, and roughly 40,000 people started using that same number as their own, assuming it was obviously fake. The SSA had to formally retire that specific number. The case shows that a 9-digit string merely looking like a sample proves nothing; only a generator that declares its synthetic origin actually guarantees that.
In practice this becomes a pipeline habit: generating the value in the browser instead of on a server keeps it from crossing the network unnecessarily, never writing the raw SSN into a query string or an application log, and making sure analytics events carry only action metadata, never the field value. Treating even a synthetic SSN as sensitive data builds the same reflex that keeps the same code path from accidentally reusing a real value in production.

Three data-minimization habits

Staging database dump

Input: SELECT ssn FROM users LIMIT 3
Expected output: 512-34-9081, 221-19-3007, 409-62-7734 (nenhum pertence a pessoa real)

A safe dump is only possible because the whole batch was generated locally, with no link to any SSA record.

Application log

Input: console.log(formData)
Expected output: campo ssn mascarado antes de qualquer linha de log

Masking the field before logging keeps the value out of a third-party log aggregator, even when it is synthetic.

Analytics event

Input: trackEvent(action, payload)
Expected output: payload sem o valor de ssn, só o metadado da ação

The event records that the field was filled in, never the digits themselves, keeping the same contract that would apply to real data.

Full tool FAQ

Does SSN have a check digit?

No. Common validation is based on structure and excluded ranges, not a checksum.

Does the SSN area indicate a state?

Is the generated SSN real?

Why exclude 666 and 900–999?

Can I use it in onboarding tests?

Is the number stored or sent?

Does this avoid already issued SSNs?

When should I use fixed fixtures?

Frequently asked questions

Why not generate the SSN directly on the server?

Data minimization: generating it in the browser keeps the value from crossing the network unnecessarily, which is exactly why this tool runs entirely on the client.

Can a synthetic SSN collide with a real person's number?

It is structurally possible, because the generator only avoids the ranges the SSA never used, without checking which numbers were actually issued. The Woolworth-wallet case shows this already happened at real scale.

What makes something a direct identifier, and does the SSN qualify?

A direct identifier singles out a person on its own, with no other field needed alongside it. The SSN qualifies because it is used in isolation for credit, employment and tax filing in the United States.

Why mask a synthetic SSN if it is not even real?

Because the discipline prevents accidentally reusing that same unmasked code path later on a route that ends up handling a genuinely real value.

Next steps

Continue in the tool

Open full tool

SSN in privacy-first sandboxes

Synthetic SSN in privacy-first sandboxes

The SSN is not just another field: on its own, it already identifies a person in the United States, with no name or address attached. This page covers why that matters in any test environment.

Why a staging dump can never hold a real SSN

In the United States the SSN is used to open credit, hire an employee and file taxes, which makes it a direct identifier: on its own it already points at one specific person, unlike a field such as birth city, which only identifies someone when combined with other data. A staging database dump with even a single real SSN turns an internal leak into a reportable incident, so the test environment must hold only a synthetic value.

Between 1938 and the 1970s a wallet manufacturer printed, as a sample insert inside every new wallet, a Social Security card carrying a real employee's number, and roughly 40,000 people started using that same number as their own, assuming it was obviously fake. The SSA had to formally retire that specific number. The case shows that a 9-digit string merely looking like a sample proves nothing; only a generator that declares its synthetic origin actually guarantees that.

In practice this becomes a pipeline habit: generating the value in the browser instead of on a server keeps it from crossing the network unnecessarily, never writing the raw SSN into a query string or an application log, and making sure analytics events carry only action metadata, never the field value. Treating even a synthetic SSN as sensitive data builds the same reflex that keeps the same code path from accidentally reusing a real value in production.

Three data-minimization habits

Staging database dump

Input: SELECT ssn FROM users LIMIT 3
Expected output: 512-34-9081, 221-19-3007, 409-62-7734 (nenhum pertence a pessoa real)

A safe dump is only possible because the whole batch was generated locally, with no link to any SSA record.

Application log

Input: console.log(formData)
Expected output: campo ssn mascarado antes de qualquer linha de log

Masking the field before logging keeps the value out of a third-party log aggregator, even when it is synthetic.

Analytics event

Input: trackEvent(action, payload)
Expected output: payload sem o valor de ssn, só o metadado da ação

The event records that the field was filled in, never the digits themselves, keeping the same contract that would apply to real data.

Full tool FAQ

Does SSN have a check digit?

No. Common validation is based on structure and excluded ranges, not a checksum.

Does the SSN area indicate a state?

Is the generated SSN real?

Why exclude 666 and 900–999?

Can I use it in onboarding tests?

Is the number stored or sent?

Does this avoid already issued SSNs?

When should I use fixed fixtures?

Frequently asked questions

Why not generate the SSN directly on the server?

Data minimization: generating it in the browser keeps the value from crossing the network unnecessarily, which is exactly why this tool runs entirely on the client.

Can a synthetic SSN collide with a real person's number?

What makes something a direct identifier, and does the SSN qualify?

Why mask a synthetic SSN if it is not even real?

Because the discipline prevents accidentally reusing that same unmasked code path later on a route that ends up handling a genuinely real value.