Four characters moved to the end, then one long division
The two digits after the country code are not part of the account number. They are a checksum, and the arithmetic behind them is deliberately simple enough that any system can run it without a lookup table. Take the number, move the first four characters to the back, replace every letter with a two-digit value where A is 10 and Z is 35, and divide the enormous integer that results by 97. A correct IBAN leaves a remainder of exactly 1.
That is ISO 7064 mod-97-10, and it is why a mistyped digit almost never survives. Run GB82WEST12345698765432 through it and the remainder is 1. Change the check digits to 99 and leave everything else alone and the remainder becomes 18. Both figures came from executing the module rather than from arithmetic on paper, and the code divides digit by digit while carrying the remainder, because the value being reduced is far past the largest integer JavaScript can hold exactly.
Six checks in order, so the failure tells you something
A single verdict of “invalid” is nearly useless when you are trying to fix a supplier record. The checks therefore run in a fixed sequence and stop at the first one that fails, so the reason you get back is the specific thing that is wrong: the character set, then a minimum shape of two letters and two digits, then whether the country code is known, then the exact length for that country, then the structure of the account portion, and only last the checksum.
The order is what makes the output actionable. A number the right length that fails only at the final step is a transposition or a bad digit. A number that fails on length was probably truncated on the way out of another system, and the message names the country and both figures so you can see how far off it is. Lengths vary widely, from Norway at 15 characters up to Saint Lucia at 32, which is precisely why a fixed-width validation rule copied from one country breaks on the next.
Pasting a column and reading the report
- Paste one IBAN into the box, or a whole column with one per line. Blank lines between them are skipped.
- Nothing needs configuring. This page has no options at all.
- Click the action button, which carries this page’s own name, IBAN Validator. It stays disabled until the box has something in it.
- Read the summary line, which counts how many passed and how many failed, then the one line per number below it. Each carries a tick or a cross, the number regrouped into blocks of four, and the verdict or the reason.
- Click Copy to clipboard to keep the report, or Process another to bring the input box back for the next batch.
That last step is worth knowing before it surprises you. When the report appears, the input box and the button are removed from the page rather than left sitting above the result, so the way back to your pasted list is the second button, not the browser’s back arrow.
Hyphens, quotes and the only separator it forgives
Normalisation here is narrow on purpose. Whitespace is stripped and letters are uppercased, and that is the whole of it. So gb82 west 1234 5698 7654 32 passes exactly as GB82WEST12345698765432 does, and a number copied out of a bank statement with its usual spacing needs no cleanup.
Anything else that is not a letter or a digit fails. A Swiss number written with hyphens between the groups, a line that kept its trailing comma from a CSV row, a value still wrapped in the quote marks a spreadsheet export added: all three come back flagged for invalid characters rather than being silently cleaned up. That is the safer behaviour, because quietly deleting characters from an account number is how a validator ends up approving something nobody typed. If your source is a file rather than a clipboard, opening it in the CSV Viewer first puts you in front of parsed cell values instead of raw delimited lines, which is where most of those stray characters come from.
What a passing IBAN still does not promise
The checksum proves internal consistency and nothing more. It cannot tell you that the account exists, that it is open, or that it belongs to the supplier whose invoice you are looking at, because none of that information is encoded in the number. A well-formed IBAN for a closed account passes every check here.
That limit is worth stating plainly because invoice fraud works precisely in the gap it leaves. An attacker who sends a convincing change-of-bank-details email supplies an IBAN that is perfectly valid and perfectly wrong, and no offline algorithm can distinguish it from the real one. Format validation catches mistakes, not deception; confirming a change of details still means calling a known number.
When the reason says too short and the number plainly is not
One rough edge deserves naming rather than hiding. The too-short reason is reused for a second condition: it also fires when the first four characters are not two letters followed by two digits. Paste a 22-character German number whose check digits were mistyped as letters and the report calls it too short, which is technically the code path taken but not a useful description of the problem. If a full-length number gets that message, look at characters three and four before you look at anything else.
Everything runs in the tab. That is not a slogan on a page like this one, it is the point: the alternative implementations of an IBAN check are paid lookup APIs that necessarily receive the account numbers of everyone you pay. The arithmetic is public and tiny, so there is no reason for the data to move at all, and no per-row cost or rate limit on a list of any size. When a number checks out, carry it into the Invoice Generator, which has no dedicated bank field but takes payment details in its free-text “Notes (optional)” box, and use Compare Excel & CSV Files to spot which rows in an updated vendor master actually changed. The rest of the developer tools category covers the surrounding data-wrangling jobs.
