ID Number Validator (Multi-Country)

What is a national ID validator?#

A national ID number is not a random string — most countries embed structure in it (a region code, a birth date, a serial) and finish with a check digit computed from the earlier digits, so that a single mistyped character makes the number fail a self-test. A validator reverse-engineers that structure: it confirms the length and character pattern are legal, recomputes the check digit from the payload, and compares. If they match, the number is well-formed; if not, someone transcribed it wrong.

This page validates ID numbers for 15 countries (China, USA, UK, Canada, Australia, India, Japan, Korea, Russia, France, Germany, Spain, Portugal, Bangladesh, Saudi Arabia), each with its own algorithm — China’s resident-ID uses an ISO 7064 MOD 11-2 table, India’s Aadhaar uses a Verhoeff dihedral-group check, Germany’s Steuer-ID uses a recursive MOD 11,10 chain, and so on. The page tells you three things separately: whether the format is legal, whether the checksum passes (some countries have none), and the normalized canonical form.

What it deliberately does not do is look anything up. There is no database, no registry, no network call — the warning banner at the top says so. A “valid” result means the number is structurally well-formed, not that it belongs to a real person.

How to use it#

1. Pick a Country from the dropdown. The list is preselected to match your page locale where possible (the Chinese page defaults to CN, the Japanese page to JP, and so on).
2. Type or paste the Number. Spaces and hyphens are tolerated and stripped; letters are upper-cased automatically where relevant (China’s X, Spain’s control letter, the UK NINO prefixes).
3. Click Validate. The result card reports a Valid / Invalid header, then four rows: Format (pass/fail), Checksum (pass/fail/not applicable), Normalized (the canonical formatted form), and Reason (which check failed — empty, format, checksum, or all-pass).
4. Clear resets the form. The whole interaction runs in your browser; nothing is stored or sent.

Key features#

• 15 countries, 15 distinct algorithms. From China’s weighted MOD 11-2 and India’s Verhoeff to France’s 97 − (n mod 97) clé (with the Corsica 2A/2B department special case), each country uses its real published checksum — not a generic Luhn bolted onto everything.
• Format and checksum reported separately. Some numbers (US SSN, UK NINO, Bangladesh NID) carry no check digit; for those the checksum row reads “not applicable” and validity rests on format alone, so you are never told a number “passed the checksum” when no checksum exists.
• Structure-aware, not registry-aware. The China validator, for instance, rejects a birthday of 19900230 (30 February) and a province prefix outside the GB/T 2260 set — structural facts about the number itself, with no lookup of who holds it.
• Normalized output. Valid inputs are pretty-printed in each country’s conventional grouping (US 123-45-6789, France 1 23 45 6L 123 456 01, Japan 1234 5678 9012), so you can copy a canonical form.
• No lookup, no storage, no network. Emphasized by the on-page warning: the input never leaves your browser. Use it to sanity-check a number you already hold; it cannot tell you whose number it is.

Worked example#

Take a synthetic, checksum-valid Chinese resident-ID constructed for demonstration: 110101199001010015 (region 110101, birth date 19900101, serial 001, check digit 5). Pasted into the CN validator, the card reads:

Status:     Valid
Format:     Pass
Checksum:   Pass
Normalized: 110101199001010015
Reason:     All checks passed

The check digit 5 is recomputed from the first 17 digits using the weights [7,9,10,5,8,4,2,1,6,3,7,9,10,5,8,4,2] and the lookup table 1,0,X,9,8,7,6,5,4,3,2 — the weighted sum is 106, 106 mod 11 = 7, and table position 7 is 5. Change the final digit to 6 and the checksum flips to Fail while format still passes — exactly how a single transcription error is caught. The birthday segment is also sanity-checked: 19900230 would fail format, because 30 February is not a real date.

For contrast, a US Social Security number like 123-45-6789 has no check digit, so its checksum row reads “not applicable” and validity depends only on the area/group/serial range rules — a reminder that “valid” means different things for different countries.

FAQ#

Does “Valid” mean this number belongs to a real person?#

No. It means the number is structurally well-formed: the right length, legal characters, a plausible structure, and (where the country has one) a correct check digit. A random well-formed number can still be unassigned, belong to a deceased person, or never have been issued. This tool cannot and does not look up who a number belongs to.

Why does the checksum row sometimes say “not applicable”?#

Because not every country puts a check digit in its ID number. The US SSN, the UK National Insurance number, and the Bangladesh NID are format-checked only — there is no self-test digit to recompute. The tool reports “not applicable” rather than pretending a checksum passed.

Is it safe to paste a real ID number into this page?#

The page is 100% client-side: there is no backend, no network request, and nothing is stored after you leave. That said, treat any real ID number with care in general — only paste it into pages you trust. If you are testing your own validation logic, use a synthetic number (as the worked example does) rather than a real person’s.

Why was my French number rejected when the digits are correct?#

The French NIR ends with a two-digit clé computed as 97 − (the 13-digit NIR mod 97), and the department slot can be the letters 2A or 2B for Corsica (which the math must treat as 19 and 18). If the clé does not match, or if a Corsican department was entered without the letter form, the number is rejected even though it “looks numeric”. Re-check the final two digits against the formula.