Skip to main content

IBAN Validator

Check an IBAN checksum in your browser, for Turkey and 75 other countries. Nothing is transmitted, and a valid checksum never means the account exists.

Your data never leaves the browserPublished: August 2026
IBAN

Enter an IBAN and the result appears here immediately.

What you type stays in your browser and is never sent to a server.

Key Takeaways

  • An IBAN checksum proves the characters are internally consistent. It does not prove the account exists, who holds it, or that it can receive money; only the bank knows that.
  • The mod-97 works on a 28 digit number. Computing it with Number() exceeds the safe integer range, which both rejects valid accounts and accepts invalid ones.
  • A length check is mandatory: mod-97 alone accepts an IBAN with a digit added or removed roughly one time in ninety seven. Turkey is exactly 26 characters.
  • The format must be checked BEFORE uppercasing. toUpperCase() maps several non-ASCII letters onto A to Z, which slips them past the check.

What a checksum tells you, and what it does not

The third and fourth characters of an IBAN are check digits, computed from the rest. If they match, you know no character was dropped or mistyped while the IBAN was written down or copied. If they do not, something is wrong.

What it cannot tell you matters more: whether the account is open, who holds it, or whether it accepts payments. Infinitely many strings satisfy the checksum and almost none of them correspond to a real account. That is why this tool reports "checksum passes" rather than "valid account".

Note

If you collect an IBAN in a form, a checksum is the first step: it catches a typo instantly and saves a pointless lookup against your bank. Only the bank can confirm the account actually exists.

The mod-97 algorithm

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

text
TR33 0006 1005 1978 6457 8413 26 1. Move the first four characters to the end:   000610051978645784132612 + TR33 2. Map letters to numbers (T=29, R=27):   0006100519786457841326292733 3. If the remainder is 1, the IBAN is valid.

Why Number() breaks the calculation

A Turkish IBAN becomes a 28 digit number under that transformation. In JavaScript, Number.MAX_SAFE_INTEGER is 16 digits; beyond that, integers can no longer be represented exactly.

javascript
// For the VALID IBAN above the true remainder is 1Number(digits) % 97   // -> 96, because of overflowBigInt(digits) % 97n  // -> 1n, correct // No BigInt needed either: every intermediate stays under 970,// so there is no overflow risk in any runtime.let r = 0;for (const ch of digits) r = (r * 10 + Number(ch)) % 97;

The insidious part is that this is invisible in review: the validator appears to work, judges some IBANs correctly and others wrongly, and nobody can reproduce the pattern. This tool uses the iterative form.

Why the length check is separately necessary

Mod-97 alone is not enough. An IBAN with a digit added or removed can still land on a remainder of 1 by chance, with a probability of roughly one in ninety seven. So about one user in a hundred would see a truncated IBAN accepted.

ISO 13616 fixes a length per country: Turkey 26, Germany 22, the United Kingdom 22, Malta 31. This tool knows the length for 76 countries and checks it first, which turns those odds into a certain rejection.

Checking ASCII before uppercasing

This was a real hole, found by measurement during development. Validating the format after uppercasing lets certain non-ASCII characters smuggle themselves in, because toUpperCase() maps them onto A to Z.

text
ıE64ıRCE92050112345678    dotless ı becomes I (it is on the Turkish keyboard)GB82WEſT12345698765432    U+017F long s becomes SGB82WEſt12345698765432     U+FB05 ligature EXPANDS to ST

The last one is the worst: a 21 character input passes a 22 character length check, because the expansion happens before the length is measured. The length check therefore validates a string the visitor never typed. The fix is to test the raw input as ASCII before any case folding.

Nothing leaves your browser

The IBAN you type is never transmitted, stored or logged. The calculation runs entirely in your browser, and once the page has loaded you can disconnect and it keeps working.

Frequently Asked Questions

The checksum passes, so is the account real?
No. A checksum only shows the characters are consistent with each other. Whether the account is open, who holds it and whether it accepts payments are questions only the bank can answer. Infinitely many strings pass, and almost none correspond to a real account.
Which countries are supported?
The 76 countries in the ISO 13616 registry. For each one the country-specific fixed length is checked first, then the mod-97 is computed. An unrecognised country code is reported as unknown rather than guessed at.
Can I paste it with spaces or in lowercase?
Yes. IBANs are conventionally written in groups of four and usually copied that way. Spaces and hyphens carry no information and are stripped, and lowercase input is accepted.
Can I use this algorithm in my own code?
Yes, and you should. Watch three things: do not use Number() for the mod-97, check the country-specific length separately, and validate the format before uppercasing.
Is the IBAN I enter stored anywhere?
No. The calculation runs in your browser and nothing is sent over the network. Load the page, disconnect, and you will find the tool still works.

Tool and article by , Senior Software Engineer. Published: August 2026.