Utilities
Validate an IBAN's country, length and check digits, and see it formatted for both electronic transfer and print. The checksum catches every mistyped digit and every swap of two adjacent digits.
Overview
Paste an IBAN and this checks three things: that the country code is one it recognises, that the length matches what that country registers, and that the check digits agree with the rest of the number. It then shows the IBAN in both the forms you need — unspaced for electronic transfers, grouped in fours for print.
The check digits are the interesting part. They are not a hash or a guess: over digits, the ISO 7064 mod-97 scheme is exhaustive — every mistyped digit is caught, and so is every swap of two adjacent digits, which is exactly the shape of the mistakes people make copying a twenty-two character string off a PDF. An IBAN with one digit wrong is essentially never also a valid IBAN.
What it cannot tell you is whether the account exists, or whose it is. That distinction is the whole reason to be careful with the result: a valid IBAN is a well-formed one. Invoice redirection fraud works precisely because the substituted account number passes every check on this page.
Nothing is transmitted. An IBAN identifies a bank account, and uploading one in exchange for a division by 97 would be a poor trade for arithmetic your own browser can do in a millisecond.
Step by step
Paste it however your bank prints it — spaces, dots and dashes are ignored, and case does not matter.
A valid IBAN shows its country, check digits and account part. An invalid one says which of those is wrong.
Electronic form has no spaces and is what transfers and forms expect. Printed form is grouped in fours, for invoices and letterheads.
Background
An IBAN is not a new kind of account number. It is a wrapper around the account number a country already used — the sort code and account number in the UK, the BLZ and Kontonummer in Germany — with two things bolted on the front: a country code, so a bank knows which national scheme to interpret the rest under, and two check digits, so a mistyped one can be caught before the payment is sent rather than after.
The check digits are computed over the whole rest of the number, which is why they detect changes anywhere in it. Move the first four characters to the end, turn each letter into a number, and divide the resulting very long integer by 97; a correct IBAN always leaves a remainder of exactly one. The scheme is chosen for its error-detecting properties rather than for elegance: over digits, every substitution changes the remainder, and so does every transposition of two neighbouring ones.
There is one gap in that, and it is worth stating rather than glossing over. Letters expand to two digits before the division — A becomes 10, Z becomes 35 — so replacing a digit with a letter makes the number one digit longer as well as different, and the guarantee, which assumes a fixed length, stops applying. Sweeping every such substitution across the published specimen IBANs finds 23 collisions out of 2,340 attempts, against none at all in the 918 digit-for-digit substitutions. It is a small hole and a real one: a checksum pass is strong evidence that an IBAN was typed correctly, not proof.
That is a strong guarantee against typing, and no guarantee at all against anything else. The arithmetic knows nothing about banks. It cannot tell you the account is open, that the bank code inside it corresponds to a real institution, or that the person who sent you the number owns the account. Those are questions only the receiving bank can answer, and it answers them when the payment arrives — or does not.
This matters because of how invoice fraud actually works. Somebody intercepts or imitates a supplier's email and changes the bank details, and the IBAN they substitute is a real, valid IBAN for an account they control. It passes the checksum. It passes the length check. It passes every offline check that exists, because there is nothing wrong with it except that it is not your supplier's. The defence is not a validator; it is confirming a change of bank details by voice, on a number you already had.
The lengths are worth knowing because they are fixed rather than variable. Each country registers exactly one length — 15 in Norway, 22 in Germany and the UK, 27 in France, 31 in Malta — so a length mismatch is a specific, findable error, and telling somebody their IBAN is one character short of a German one is far more useful than telling them the check digits do not match. Checking length first is why this reports the former.
Reference
Only the first four characters have a fixed meaning everywhere. What follows is a national account number, formatted however that country decided, which is why the total length differs from one to the next.
Characters 1–2: the country code
Two letters, from the same list as country codes generally. It tells the receiving system which national format the rest is in — without it, the remaining characters are ambiguous.
Required
Characters 3–4: the check digits
Two digits, computed from everything else. They exist to fail when the rest has been mistyped, which is the only job they have and one they do exhaustively.
Required
Characters 5 onwards: the account part
The country's own account number, sometimes with a bank identifier at the front and sometimes with its own internal check digit. There is no universal rule for what sits where.
Required
The length
Fixed per country, from 15 to 34 characters. Not a range and never optional, which is what makes a length mismatch a precise error rather than a vague one.
Required
The characters allowed
Uppercase letters and digits only. Spaces, dots and dashes are printing conventions, not part of the number, and must be stripped before anything electronic.
Required
What is not in it
The account holder's name, the bank's name, the currency and the branch address. An IBAN identifies an account and nothing about who owns it.
Optional
What no IBAN has
Any part that proves the account is real. Validity and existence are separate questions, and only the receiving bank can answer the second one.
Optional
Who it helps
One wrong character means a payment that bounces after a week, or lands somewhere unexpected. Checking before the IBAN goes on the invoice is cheaper than either.
The IBAN on your own invoice template gets retyped from a bank statement once and copied for years. It is worth checking exactly once, properly.
A supplier's details are entered from a PDF, and the checksum catches the transcription errors that come with that. It cannot catch the supplier whose email was intercepted.
A first payment to a new account is when fraud lands. The checksum is worth running and is not the check that matters — confirming the details by voice is.
The mod-97 rule is short enough to implement and easy to get subtly wrong, particularly the part where letters expand to two digits and the number outgrows a double.
A rejected payment usually means a malformed IBAN or one for a closed account. This separates the two: if it fails here, the number was wrong before it reached the bank.
Do it properly
Bank details are typed once and reused for years. An error caught at the point of writing costs a minute; the same error found by a failed payment costs a fortnight of emails.
Machines want the unspaced form and people want the grouped one. Keeping the electronic version as the source of truth prevents spaces being pasted into a form that rejects them.
Use a number you already had, not one on the invoice. A substituted IBAN is a valid IBAN, so no amount of checking the number itself will tell you it changed hands.
If the length is wrong for the country, characters were dropped or duplicated rather than mistyped. Recount against the original instead of re-reading it character by character.
The two letters are part of the IBAN, not a label. An account part on its own cannot be validated and cannot be routed internationally.
Most IBAN errors are transcription errors, and the checksum exists because they are so common. Copying removes the failure mode rather than detecting it.
A BIC, the bank's name, or the last few characters confirmed separately. Cross-checking two things a fraudster would have to get consistent is more use than checking one twice.
Avoid these
Reading a valid IBAN as a safe one
Treat validity as "typed correctly", nothing more. The account may not exist, may be closed, and may belong to somebody else entirely — none of which the number itself can reveal.
Correcting the check digits to make it validate
Recheck the account part instead. Rewriting the check digits over a mistyped account number produces a perfectly valid IBAN for the wrong account, which is why this tool declines to offer it.
Pasting the spaced version into a transfer form
Use the unspaced form for anything electronic. The grouping is a printing convention, and many systems reject it rather than stripping it for you.
Acting on new bank details in an email
Phone the supplier on a number you already had and confirm. Invoice redirection is the most common way businesses lose money, and it defeats every offline check because the substituted IBAN is genuine.
Assuming every country has an IBAN
Check the destination first. The United States, Canada and Australia do not use IBAN, and a form demanding one for a US account is asking for something that does not exist.
Treating an unfamiliar country code as an error
Verify the code rather than the number. Countries join the IBAN scheme, so a code a validator does not recognise means its list is out of date, not that the account is invalid.
Sending the payment before checking anything
Validate first, then confirm the recipient separately. A cross-border transfer can take a fortnight to bounce back, and one to an account that exists but is not your supplier's may not come back at all.
FAQ
The IBAN Validator is at the top of this page — free, no signup, nothing uploaded.
More tools
Guides
Articles that go deeper than this page has room for.