Free IBAN checker: validate any IBAN number in seconds

What an IBAN checker validates

An IBAN checker confirms that an International Bank Account Number is built correctly. It checks the country code, the total length for that country, the two check digits, and the national bank and account structure. A valid IBAN means the number is well formed, not that the account behind it is open.

Paste an IBAN above and the checker returns:

• Whether the ISO 13616 checksum and the country length both pass
• The issuing country, read from the first two letters
• The bank code, the branch code where the country uses one, and the account number

All of that comes from the IBAN itself, so the check runs in your browser and the number is never sent anywhere. The checker does not name the account holder and does not confirm the account is open. No IBAN validator can do either of those from the number alone.

How IBAN validation works

Every check runs the same three steps in order, and each one rejects numbers the step before it accepted:

1. Format: spaces are stripped and letters are uppercased. An IBAN holds only letters and digits, and it always starts with a two-letter country code followed by two check digits.
2. Length: every country publishes one fixed IBAN length, from 15 characters in Norway to 33 in Malta. A German IBAN is always 22 characters, so the wrong length alone is enough to reject a number.
3. Checksum: the first four characters move to the end, each letter becomes a number, and the result must leave a remainder of 1 when divided by 97. That is the mod 97 test defined in ISO 13616.

The mod 97 step is what catches typos. Change one character and the remainder almost never stays 1, so a single mistyped digit is caught before the payment leaves your account.

What an IBAN checker cannot tell you

A valid IBAN and a usable account are two different things. A number can be perfectly formed and still fail once the payment reaches the bank.

It cannot return the account holder's name. Name matching, such as Confirmation of Payee, runs inside the banking network and is not available from the number.

It cannot tell you whether the account is open, frozen, or closed, and it cannot see a balance. Only the receiving bank knows that.

It also cannot supply the bank's name or BIC. Those come from a bank registry rather than from the number itself, so any tool that shows them is reading a separate data source.

Use cases for IBAN validation

Payment and checkout forms: check the IBAN while the user is still on the page. A typo caught at entry costs nothing. The same typo caught by the bank costs a returned transfer fee and a support ticket.

Payroll and supplier onboarding: validate every IBAN before the first payment run so one bad number does not hold up a whole batch.

Invoicing and reconciliation: reject malformed bank details at upload instead of discovering them halfway through a payment file.

Data cleaning: run stored IBANs through the same check and flag the rows that fail. Records collected before any validation existed are where most bad numbers sit.

From the command line: the same check runs with one request. Replace YOUR_API_KEY with a free key.

Building it into a product? Abstract's IBAN Validation API returns is_valid for every IBAN you send, and the docs cover the request format, the error codes, and the free tier.

‍

‍