The Three Digits Most SSN Validators Get Wrong
You paste 123-45-6789 into a form, the regex turns green, and the database accepts the row. A few weeks later, the IRS rejects the W-2 because the area number 123 has not been issued in over than a decade. Or worse, the form accepted 666-12-3456 and you never noticed, because your validator pattern only checks the shape of the string, not what the Social Security Administration has actually issued since 1936.
The shape check is where most teams stop, and it is the reason a small validator library has quietly become one of the most useful pieces of plumbing on Elysia Tools. The US SSN Validator is not doing anything exotic. It is doing the boring thing well: it checks the format, then it checks the area, group, and serial ranges the SSA has actually used, then it flags the values that are syntactically correct but functionally impossible.
What a Real SSN Format Check Has to Verify
A social security number is three fields: a three-digit area number, a two-digit group number, and a four-digit serial number, traditionally written as AAA-GG-SSSS. The dash is purely cosmetic. The SSA has never required it, every tax form since 1972 has accepted the run-together form, and your backend should accept both. But the digits themselves are governed by a handful of rules that have accreted over ninety years, and most regex patterns do not encode any of them.
The rules that matter, in order of how often they get missed:
- The area number can never be
000. There are no SSNs issued in the 000 area. - The area number can never be
666. The SSA reserved this block in 1936 and has never used it. - The area number can never be in the range
900through999. These blocks were used for ITINs (Individual Taxpayer Identification Numbers) and are deliberately excluded from the SSN namespace to prevent confusion at the IRS. - The group number can never be
00. There are no SSNs with a zero group. - The serial number can never be
0000. There are no SSNs with a zero serial. - The specific number
078-05-1120was used on a sample wallet card advertising the program in the 1940s and appears in millions of records. The SSA has published it as a known-promiscuous value; if you ever see it in a production dataset, it is a default someone pasted, not a real person.
A regex that only checks ^d{3}-?d{2}-?d{4}$ accepts all six of those failure modes. A regex that adds the area-number rules cuts the false-positive rate on real-world dirty data dramatically, which is the difference between a validation pass that catches 99 percent of typos and one that catches 99.7 percent.
The Patterns Real Systems Are Using
If you pull a few popular open-source SSN validators on GitHub, you will find three patterns repeated. The first is the bare shape check, which is the pattern most teams ship. The second is the shape check plus the 000 and 666 area exclusions, which is what most “SSN validator” libraries actually implement. The third, and the rarest, is the one that also excludes the 900-series and the 078-05-1120 number.
Most teams settle for the second pattern because the third is harder to find codified. There is no official SSA API for SSN validation. The agency publishes the area-number rules in a periodic numbering guideline that is genuinely difficult to locate on ssa.gov because it is buried under multiple layers of reorganization. The rules have not changed materially since 2011, but they are also not promoted to the kind of developer-facing documentation a backend team would naturally find while wiring up a form. The Elysia Tools validator codifies all six rules in one pass and returns a structured result that names the specific reason for rejection, which is what makes it useful in a form-validation pipeline where you want to surface a meaningful error to the user instead of a generic “invalid SSN.”
Why a Validator That Returns a Reason Is More Useful Than One That Returns a Boolean
The difference between a regex and a structured validator shows up the first time you wire it into a multi-step form. A regex returns true or false, and the frontend has to invent an error message. A structured validator returns a list of named failure modes, and the frontend can map each one to a specific user-facing string. The SSN is too short to be PII-adjacent in a way that a vague error helps, but a clear one does.
For a form that asks for an SSN, the user-facing error “the area number 666 is reserved and has never been issued” is more helpful than “this does not look like a valid SSN” because it tells the user what to fix. The same is true for the 900-series: many users will type a number out of memory, and if they type 987-65-4321, the correct response is “this falls in the ITIN range, please double-check that you are entering an SSN and not an Individual Taxpayer Identification Number,” not a generic invalid-SSN banner.
This is the same reason the US SSN Validator on Elysia Tools returns a structured object with a valid flag, a normalized form (the run-together digits, the dashed form, and the original input), and a reasons array naming every rule the input failed. You can wire it into a form with three lines of code and the rest of the work is presentation, not parsing.
Sample Inputs and What the Validator Returns
The US SSN sample collection ships with the canonical edge cases. The valid examples include numbers from each geographic area (the 700-series from the railroad board, the 800-series added in 1972 when the original 700-series was exhausted, the 200-series from the 1973 randomization). The invalid examples cover the 000 area, the 666 area, the 900-series ITIN range, the 078-05-1120 wallet-card number, and the malformed inputs (wrong digit count, alphabetic characters, dashes in the wrong place).
Running these through a typical regex-only validator returns the same true/false answer for each: true for the valid set, false for the invalid set. Running them through the Elysia Tools structured validator returns a richer picture. The 666-12-3456 input comes back as invalid with area_reserved in the reasons array. The 987-65-4321 input comes back as invalid with area_itin_range. The 078-05-1120 input comes back as invalid with known_test_value. The shape-malformed inputs (12-345-6789, 123-45-678, ABC-DE-FGHI) all come back with format_mismatch.
For a form-validation pipeline, that distinction is the difference between an error message that says “the area number you entered is in a reserved block that the SSA does not issue” and one that says “this does not look like a valid SSN.” Both reject the input, but only the first one tells the user what to do next.
What to Put in Your Own Validator
If you are building an SSN check from scratch, the minimum viable ruleset is the area-number exclusions, the group and serial zero exclusions, and the wallet-card number check. If you want to be thorough, also exclude the 900-series ITIN range and the historical 700-series railroad board block (which is now exhausted but still in some older datasets). If you want to be very thorough, the SSA’s numbering guideline also flags area numbers that were valid in the past but are no longer issued, which is the kind of check that turns a validator into a small data service.
The Elysia Tools US SSN Validator ships with the minimum viable ruleset by default, and that is the right baseline for a general-purpose form. The full historical ruleset is a useful extension for a finance or healthcare application where you need to catch a number that was valid in 1985 but is not in the 2026 active range, but for most form-validation use cases the minimum viable ruleset is what you actually want.
The most important thing is that the validator exists. The shape-only regex is the most common SSN check in production today, and it is the one that lets 000-12-3456 and 666-12-3456 through the form. A two-line swap to a structured validator is the smallest change a team can make to a form that materially reduces the false-positive rate on real-world data.
For more tools like this one, browse the rest of the Elysia Tools validators and form helpers. The US SSN Validator is one of a small cluster of form-validation utilities, and it follows the same shape as the credit card, IBAN, ISBN, and phone number validators in the same family.
