Validating an Israeli ID Number in Code: The Check Every Lead Form Needs

An Israeli ID number is nine digits, the last of which is a check digit computed with the Luhn method. Multiply the digits alternately by 1 and 2 from left to right, replace any two-digit product with the sum of its digits, and the total must be divisible by 10. The check catches typing mistakes. It does not identify a person.

How the check digit is calculated

The algorithm is a Luhn variant over nine digits, with the check digit itself included in the sum:

1. Normalise the input to exactly nine digits, padding with zeros on the left.
2. Walk the digits left to right, multiplying alternately by 1 and 2, starting with 1 on the first digit.
3. If a product exceeds 9, subtract 9 from it. That is identical to summing its two digits.
4. Add the nine results together.
5. The number is valid if and only if the total is divisible by 10 with no remainder.

A synthetic example: 123456782. Its digits run in sequence, so it clearly does not belong to a real person.

The total is 40, which divides by 10, so the number passes. A single wrong digit, or two adjacent digits swapped, will almost always be caught.

Why is zero-padding the most common bug?

Because older ID numbers are shorter than nine digits, and interfaces display them without their leading zeros. A user types eight digits, the code runs over eight, the alternating weights start on the wrong position, and every short number is rejected as invalid.

• Normalise every input with padStart(9, '0') before the calculation, not after it.
• Strip spaces and hyphens before padding, not at the end of the pipeline.
• Always store the value at length nine, as a string. A numeric database column destroys the leading zero silently.
• Never compare ID strings across two systems without normalising both first. That is a classic source of duplicate customer records.

Does a valid number prove this is that person?

No, and that distinction is the whole point. The check digit tests internal mathematical consistency and nothing else. Anyone can generate nine digits that satisfy the calculation in seconds, and most real people's ID numbers satisfy it too - which is exactly the intent.

So the check has one legitimate use: reducing typing mistakes before a value enters a system. It is not suitable for opening an account, releasing information, identifying a caller, or any decision that affects a person. Those require verification against an external source, or a mechanism such as a one-time code sent to a pre-registered phone.

Where to run the check, and what to do with the result

The simple rule is browser for convenience, server for truth. A validation failure on a lead form should be a soft warning that still lets the visitor submit, not a hard block - a form that rejects a lead over one digit deletes an enquiry sales would have closed on the phone.

Normalisation, duplicates and test data

The check itself is a small part of the work. Most of the trouble that shows up afterwards comes from the same number being stored in three different shapes across three systems.

• Normalise before comparing, never after: strip spaces and hyphens, then pad to nine digits. In that order and no other.
• Match on the normalised value when merging a lead into an existing customer. Matching on raw input creates two records for one person.
• Store the normalised value in a field separate from the original input. When somebody insists they typed it correctly, you can show what was actually submitted.
• Do not use the number as a primary key. People mistype it, and a primary key that changes breaks every relation hanging off it.
• For automated tests, generate valid synthetic numbers in code rather than copying real ones into a development environment.

That last point matters more than it sounds. A real ID number pasted into a fixture file eventually reaches git, log aggregators, and environments that were never meant to hold it.

What to collect, and what not to

Israel's Privacy Protection Authority published an opinion on collecting ID numbers and photographing ID cards, in which it notes that an ID number is a unique identifier acting as a key to further personal information, that it should only be collected where genuinely required, and that less intrusive identification methods should be preferred.

• Do not ask for an ID number at the lead stage if it is only needed at contract stage.
• If it is needed, say why on the form, in one sentence.
• Show a partially masked value on internal screens rather than the full number.
• Never put it in a query-string parameter, or in a request body that gets written to logs.
• Define a deletion policy. A lead that never became a customer should not hold an identifier forever.

This is a technical description of a validation mechanism and of a published official document, not legal advice. Binding requirements must be checked against the official source.

Related: form design that converts, automating lead routing, validating Israeli public vehicle data.

Sources

• Opinion on collecting ID numbers and photographing ID cards - Israel Privacy Protection Authority