IBAN validator

What is an IBAN validator?

An IBAN is the international format for a bank account number: two letters for the country, two check digits, then whatever the country uses domestically. The check digits are the interesting part. They are computed from every other character, so if any one of them is typed wrong the sum no longer comes out right, and the mistake is caught before the payment is sent anywhere.

An IBAN validator runs that arithmetic. Move the first four characters to the end, replace each letter with a number where A is 10 and Z is 35, read the whole thing as one long integer, and take the remainder modulo 97. A valid IBAN leaves a remainder of exactly 1. That is the entire algorithm, it is specified as ISO 7064 MOD 97-10, and it needs no database of any kind.

That last point is worth dwelling on, because it decides what this page can honestly claim. Checking the check digits is pure arithmetic and always correct. Anything else, such as which country a code belongs to or how long that country's IBAN should be, comes from a published registry that changes over time. This tool keeps the two apart and tells you which is which.

How to use it

1. Paste an IBAN, with or without spaces. Spaces and hyphens are ignored and lower case is accepted, so an IBAN copied off an invoice in blocks of four works as it stands. There is nothing to select and no country to choose first: the country is read off the first two letters.
2. Read the verdict. The panel says whether the check digits are valid. When they are not, it shows the two digits the rest of the characters imply, which usually points straight at what went wrong. Below that sit the country, the length, and the length the registry gives for that country.
3. Check the length row, not just the verdict. The check digits and the length catch different mistakes, and the length row is the only thing that catches the one described below. Where the country code is not in the snapshot, the tool says so rather than calling the IBAN invalid.

What it catches, counted rather than repeated

The usual claim is that mod 97 catches essentially everything. Rather than repeat it, we measured it. Taking valid IBANs across the full legal range of lengths and changing them one error at a time, 229,779 errors that keep the number the same length were tested: any character replaced by another of the same kind, and any two characters swapped at any distance apart rather than only neighbours. Not one escaped.

That is worth putting beside the two modulo-10 schemes this site has already measured the same way. The Luhn algorithm, which guards bank cards and IMEI numbers, misses 2.20% of neighbouring swaps, all of them the single pair 0 and 9. ISBN-13 misses 10.21%, five different pairs. Mod 97 misses none of them, and unlike the other two its guarantee is not limited to adjacent characters.

The reason is arithmetic rather than luck. Every position in the number carries a weight, and those weights are the powers of 10 modulo 97. Because 10 is a primitive root modulo 97, those powers cycle through 96 distinct values before repeating, so no two positions in a real IBAN share a weight. And because 97 is prime and larger than the gap between any two characters, a difference at any position always moves the remainder. Both facts are needed; either alone is not enough.

There is a horizon, and it is precise. Two characters exactly 96 digit-positions apart do carry the same weight and swapping them is genuinely invisible, which we checked directly. But the longest IBAN the standard permits is 34 characters, and even if every one of them were a letter it would expand to only 66 digits. The scheme has a blind spot that IBAN is too short to reach.

The one thing it cannot see

Errors that change the length are a different matter, and there the guarantee does not hold. Dropping or adding a character escapes about once in 97 times, which is exactly what a modulus of 97 predicts and what we measured at 0.98%. That is the ordinary background rate of any checksum, and there is no getting under it without more check digits.

One case, though, is not a matter of chance at all. A leading zero is completely invisible to the arithmetic, because putting a zero in front of a number does not change its value. Adding or removing one at the front of the account number left the IBAN passing 616 times out of 616 in our sweep: not one in 97, but every single time. Plenty of countries issue account numbers that begin with a zero, so this is not a hypothetical.

That is precisely why the tool checks length at all. The check digits and the length are not two ways of doing the same job; the length is the only thing standing between you and the one error the arithmetic is structurally incapable of noticing. When the account number you paste starts with a zero, the tool says so and points you at the length row.

It is also why the length never overrides the verdict. The country lengths come from the ISO 13616 registry, for which SWIFT is the registration authority, and the snapshot here is Release 99 of December 2024, holding 89 country codes. Comparing that against a copy of the registry from a decade earlier shows 30 countries added and none removed, which sounds like a table that can only ever be incomplete. But one length also changed: Costa Rica moved from 21 characters to 22 in 2017. A tool that rejected an IBAN because its own table disagreed would have called every new Costa Rican account invalid for as long as it went un-updated. So here the checksum decides, and the table only ever adds an observation to it.

Honest limits

Many countries embed their own check digits inside the account number, underneath the IBAN's. Belgium's are themselves a mod 97 taken over the first ten digits of the account number, which we verified on a published Belgian IBAN; Spain, France, Italy, Norway and the Netherlands each use something different. This tool does not check any of them, so an IBAN can pass here and still be malformed for its own country. Only a check built for that country can tell you.

A valid IBAN also says nothing about whether the account exists. It means the characters are consistent with one another, so whoever typed them probably did not slip. It does not mean the account was ever opened, belongs to anyone in particular, or can receive money, and no arithmetic performed on the number itself can establish any of that. Only the bank holding the records knows, and any page claiming to verify an account without contacting one is doing exactly what this page does.

There is no bank identification here either. The characters after the country code do encode a bank and often a branch, but resolving them means a directory that is not fully public and that changes as banks merge and split, and a stale copy would be confidently wrong. The tool reports what it can derive and stops there.

One more thing worth knowing if you compare tools: a dozen or so two-letter codes that other validators list are not IBAN countries at all. Åland uses Finland's format under FI, and eleven French overseas territories use France's under FR, so no bank issues an account beginning with those codes even though the arithmetic would happily accept one. A further 22 countries, among them Morocco, Algeria, Iran and Senegal, do have formats in real use that are not in the ISO registry; those are labelled rather than hidden or silently accepted.

Why is it free?

Because it is a remainder. There is no server in the loop and nothing to download: the whole check runs in your browser, and nothing you paste is uploaded, logged or stored anywhere. On a page where people paste bank account numbers that matters more than usual, which is why the arithmetic deliberately needs no lookup.

So there is no account, no sign-up and nothing held back. The engine and the 209 checks that verify it sit in the repository beside the page, including the sweeps behind every figure quoted above.