TCKN, VKN and IBAN Validator

What a checksum tells you, and what it does not

A check digit is computed from the rest of the number. If it matches, there is no transcription error in the digits. If it does not, something is wrong. That is the entire content of the signal.

What it cannot tell you matters far more: whether the number was ever issued, who holds it, or whether it is still current. Infinitely many numbers satisfy any of these checksums, and almost none of them belong to anyone. This is why the tool reports "checksum passes" rather than "valid person".

The national ID algorithm

Eleven digits, never starting with zero. The last two are derived from the first nine.

1d10 = ((d1+d3+d5+d7+d9) * 7 - (d2+d4+d6+d8)) mod 102d11 = (d1 + d2 + ... + d10) mod 10

The trap is that the subtraction can produce a negative number. JavaScript's % operator computes a remainder rather than a mathematical modulo, and it keeps the sign of the left operand. The computed digit is then negative and can never equal the real one.

1// Wrong: rejects VALID identifiers such as 191919191902const d10 = (odd * 7 - even) % 10;3 4// Right: brings the result back into 0-95const d10 = (((odd * 7 - even) % 10) + 10) % 10;

This is invisible in review because most identifiers are unaffected: only the ones whose intermediate sum goes negative break. A user enters a genuine ID, the system rejects it, and nobody can reproduce the problem.

Fakes that pass the checksum

When the first ten digits are identical, the rules force a particular eleventh digit, so the number satisfies both checks. 11111111110 is the best known of these and appears in nearly every tutorial and test fixture in the country.

The tool reports these as their own category. Saying "checksum failed" would be untrue, because it did not fail; saying "valid" would be considerably worse. The honest answer names it as a well-known test value.

The tax number uses a different algorithm entirely

Ten digits, and unrelated to the national ID rule. Each digit gains a position weight, the result is taken modulo ten, then folded through a power of two and reduced modulo nine.

The step everyone drops is that a modulo-nine result of zero counts as nine. Without that branch a validator rejects a substantial share of genuine tax numbers.

IBAN, and the overflow that breaks it

IBAN validation is ISO 13616: move the first four characters to the end, map letters to numbers (A=10 through Z=35), and the resulting value modulo 97 must equal 1.

A Turkish IBAN becomes a 28 digit number under that transformation. Number.MAX_SAFE_INTEGER is 16 digits, so computing the remainder with Number() produces nonsense.

1// For a VALID TR IBAN the true remainder is 12Number(digits) % 97   // -> 96, because of overflow3BigInt(digits) % 97n  // -> 1n, correct4 5// No BigInt needed, and safe in every runtime:6let r = 0;7for (const ch of digits) r = (r * 10 + Number(ch)) % 97;

A length check is required as well. Mod-97 alone accepts an IBAN with a digit added or removed roughly one time in ninety seven. Turkey is exactly 26 characters, and checking that turns those odds into a certain rejection.

Why there is no generator

All of these checksums are trivially invertible. Choose nine digits freely, derive the last two, and you have a well-formed identifier in constant time with no search involved. Writing a generator is technically nothing.

That is exactly why there is not one. The algorithms are published by the issuing authorities, so a validator gives a bad actor nothing they lack. A button that emits a hundred well-formed numbers, or a bulk mode that screens a pasted list for the plausible ones, is a different thing entirely: those are the fraud-relevant primitives, and both are absent by design.

Nothing leaves your browser

What you type is never transmitted, stored or logged. The computation runs entirely locally, and once the page has loaded you can disconnect and it keeps working. Given that the input is personal data by definition, that is a requirement rather than a feature.