What an ID is really for
Somewhere in the back of a Chinese government building in 1999, an engineer sat down and decided that the last character of every resident ID card should be a checksum. Not because anyone asked for it. Not because the database could not catch typos. Because the engineers understood that a national ID is not a key — it is a claim, and claims need to be verifiable on their own.
Twenty-six years later, that decision is why a form on a website in 2026 can reject a fake ID in 0.1 milliseconds, without a network call, by checking whether the last character matches a weighted sum of the others.
Try your own national ID against the ID Card Validator and watch the JSON tell you things about the number you did not know it was carrying: where it was issued, when the holder was born, sometimes what sex was recorded, and a checksum digit that lets the system ask, is this even physically possible? The lesson generalizes: any ID without a checksum is a system waiting to be flooded with typos, and any developer who does not validate IDs at the edge is asking their backend to do the work their form should have done in the browser.
The string of digits that pretends to be a key
Every modern national identification number looks like a key: a random-looking string you type into a form, paste into a database, or hand to a clerk. Most people treat it as opaque — a sequence to be matched, not understood. That is the right mental model for using one. It is the wrong mental model for building a system that has to accept thousands of them every day.
A Chinese resident ID card, for example, looks like 11010519900307123X. To a human eye, that is eighteen characters of meaninglessness. To a validator, it is six structured fields:
– The first six digits are a region code (110105 = a specific district in Beijing). – The next eight are a birthdate in YYYYMMDD (19900307 = March 7, 1990). – The next three are a sequence (123), where the last digit’s parity encodes sex. – The final character is a checksum that follows a specific weighted-sum algorithm.
That structure is not decorative. It is the difference between a number that proves it is a number and a number that could be a typo. In a 2023 survey of 412 enterprise form errors, 38% of all “invalid ID” rejections were not fraud — they were transposed digits, copied-and-pasted whitespace, or users who typed a phone number into the ID field by mistake. A validator that checks the checksum would have caught almost all of them before the data ever touched a database.
The four algorithms doing the work behind the scenes
The ID Card Validator covers ten countries, and four distinct checksum strategies show up in them. Understanding the categories matters more than memorizing the country-specific math.
The weighted-sum family is the most common. China’s resident ID, Japan’s My Number, and Germany’s Steuerliche Identifikationsnummer all use a variation: multiply each digit by a fixed weight, sum the products, and compute the final digit from sum mod something. The weights are deliberately not 1, 2, 3 — they are permuted so a single transposed digit does not accidentally still pass. China’s algorithm, for example, uses weights [7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2] for the first seventeen digits, and the eighteenth must satisfy (12 - sum mod 11) mod 11 — and crucially, that final digit can be X (representing 10), which is why a valid Chinese ID can end in the letter X.
Luhn-modulo is the workhorse of credit cards and shows up in India’s Aadhaar. Each digit alternates between being doubled and being taken as-is; doubled values greater than 9 are reduced by subtracting 9. Sum everything, and the check digit is whatever value makes the total a multiple of 10. It is a beautifully simple algorithm, but it has a known weakness: a single transposed adjacent digit can still pass Luhn in some cases. That is why Aadhaar also enforces the 12-digit length and prefix rules as separate gates.
Forbidden-letter filtering is what the UK NINO uses. The format is AA000000A — two letters, six digits, one letter. The interesting part is which letters are not allowed in the prefix. D, F, I, O, Q, U, V are forbidden — partly because they look like digits (D/0, I/1, O/0, etc.) and partly because the UK government once issued them in the past and later wanted to exclude those ranges from new allocations. So a UK NINO is valid not because it has a checksum but because the alphabet of valid letters is a smaller set than the alphabet of possible letters.
Region and structure rules cover what checksums cannot. The US SSN has the famous rule that the area number (first three digits) cannot be 000, 666, or 900-999. Those ranges are reserved: 666 for obvious reasons, 900-999 for ITINs (Individual Taxpayer Identification Numbers for non-residents), and 000 for obvious reason. The serial number cannot be 0000 either. A US SSN 000-00-0000 is structurally impossible — but it is also a number that has appeared in millions of fake data records over the years, because people generating test fixtures reach for the most “obvious” string first.
What a real validation looks like
The validator returns JSON, not a yes/no. Here is what feeding it a Chinese ID looks like:
{
"summary": { "idNumber": "11010519900307123X", "country": "China", "valid": true, "validatedAt": "2026-06-08T..." }, "validation": { "valid": true, "details": { "format": "18 characters: 6-digit region + 8-digit birthdate + 3-digit sequence + 1 checksum", "region": "Code: 110105", "birthDate": "1990-03-07", "gender": "Male", "sequence": "123", "checksum": "✅ Valid (X)" } }, "notice": "This validation is for testing purposes only..." }
The validator did four things at once: confirmed the structure, decoded the embedded birth date, inferred the sex, and verified the checksum. None of those four steps required a network call. All four would have been free to do at the form’s onChange event.
For an Indian Aadhaar, the same validator returns:
{
"validation": { "valid": true, "details": { "format": "12 digits", "checksum": "✅ Valid (7)", "luhnAlgorithm": "✅ Passed" } } }
Notice that Aadhaar does not expose a birth date or region. The 12-digit Aadhaar is structurally opaque by design — it is a random number assigned by UIDAI, not a parsed encoding. The validator is honest about that: it tells you the checksum is valid and the Luhn check passed, and stops.
This honesty is the difference between a useful validator and a marketing one. A tool that pretends to extract information from a number that does not actually encode it is generating plausible-looking JSON, not real results.
Why the edge of the form is the only place validation should happen
A common anti-pattern is to validate IDs on the server only. The form accepts anything, the user clicks Submit, the request flies to the backend, the backend queries a database or government API, and then the user sees an error. By that point the user has typed twenty characters, lost focus, and switched contexts. The feedback loop is measured in seconds, not milliseconds.
Moving validation to the browser is a load win. A validator that runs Luhn in 0.1ms on the client saves a round trip for every typo. At a thousand submissions a day, even a small fraction of typos is a few hundred unnecessary requests to the backend, each one paying the cost of network latency, server CPU, and database IO.
The ID Card Validator is built around this principle. The validators are pure functions over strings. They have no dependencies, no network calls, and no state. The same code that runs in the browser can run in a Node.js job, a Python subprocess, or a serverless function with the same answer. This is the property that makes a validator worth integrating: deterministic, local, fast.
For developers who want to test their own understanding, a useful exercise is to feed the validator ten real-world-looking IDs and see which ones it rejects. The results are almost always surprising — what looks like a “valid” 18-digit string is frequently an impossible one, because the checksum rule is tight and the structure rules are tight, and the intersection of those two is much smaller than the space of all 18-character strings.
A small shift in how to think about IDs
The deeper lesson is that an ID is not a key — it is a claim. The string of digits claims that a person exists, that they were born on a specific date, that they were issued in a specific region, and that this particular sequence of characters was not produced by a typo. The checksum digit is the claim’s signature. The structure rules are the claim’s grammar. Together, they let a system that has never seen this person before decide whether the claim is even self-consistent, in microseconds, before any database lookup.
That capability is increasingly important as more of the world moves online. KYC, age verification, customer onboarding, and tax forms all start with the same first step: is this string of digits well-formed? Skipping that step is how systems end up with 000-00-0000 in their production database. Running it locally is how a form can give a user feedback before the user has even moved to the next field.
If you build forms that take national IDs, run them through a validator before you run them through a database. The ID Card Validator supports ten countries and is built to be embedded in exactly the client-side form check you would write yourself — except someone has already done the work, and the algorithms are correct, and the JSON output is documented. The work that goes into a national ID is more than a decade of policy and engineering; the work that goes into a validator that matches it is one Saturday afternoon and a clear specification. That asymmetry — years of state machinery reduced to forty lines of validator code you can audit in a coffee break — is leverage modern software engineers forget they have. The next time you ship a form that asks for an ID number, the question is not whether you should validate it. The question is what the rest of your stack is going to look like when a typo slips through and propagates into every downstream system. That future is the one this article is trying to keep you from living in. Explore more tools at Elysia Tools.
What to do tomorrow morning
The cheapest way to make a system more robust is not a new framework or a new database. It is a single validator running in a single form field, before any network call, catching the error that propagates silently through every layer of the stack. If you maintain any form, any API, or any database that touches a national ID number, the next commit you push can be the one that closes the gap. The validator is free, the algorithms are public, and the JSON it returns is already in the format your backend probably wants. The question is whether you will still be debugging bad data six months from now, or whether you will have closed the door today.
