Developer tool
IBAN Generator
Generate a random IBAN number that matches a country's format and passes the ISO 13616 MOD 97 check. Use these fake values for development, demos, and payment-form tests only.
How this random IBAN generator works
The generator reads the selected country's ISO 13616 BBAN pattern, fills its numeric and alphanumeric fields with random test characters, then calculates the two check digits required for MOD 97-10. It does not query a bank, reserve an account, or verify that a value belongs to anyone.
Why IBAN formats differ by country
Every IBAN starts with a two-letter country code and two MOD 97 check digits. The remaining Basic Bank Account Number, or BBAN, follows rules set by that country's banking system. Those rules determine the total length, whether a field accepts digits or letters, and where local bank, branch, routing, and account identifiers appear. There is no single account-number template that can be reused worldwide.
A German IBAN is 22 characters and its BBAN is numeric. A UK IBAN is also 22 characters, but begins its BBAN with a four-letter bank identifier followed by a sort code and account number. France uses 27 characters and permits letters in part of the account field, while a Dutch IBAN is only 18 characters and includes a four-letter bank code. The selected country therefore changes more than the prefix: it changes the entire field pattern that this generator must satisfy.
Spaces are only a readable display convention and are not part of the electronic IBAN. Applications should normalize spaces and letter case before validation, then apply the selected country's exact length and BBAN pattern. A successful MOD 97 check confirms that the characters are internally consistent; it does not confirm that the embedded bank or account identifiers have been issued.
Random IBANs vs fixed fake IBANs
Use a random IBAN when you want varied, structurally valid input across repeated tests. Random fixtures are useful for exploratory testing, form demos, property-based checks, and finding code that accidentally depends on one familiar account length or prefix. Generate values for several countries to exercise numeric, alphabetic, and mixed BBAN fields rather than testing only the default German format.
Use a fixed fake IBAN when a test must be reproducible. Snapshot tests, support documentation, automated browser scripts, and expected API payloads are easier to debug when the same fixture produces the same result every time. This generator is not seeded, so save an appropriate generated value in your test fixtures instead of expecting the next click to recreate it. Label it clearly as synthetic data.
In both cases, "fake" means the value was produced without looking up or opening an account. Because the account space belongs to real banking systems, a generated string must never be treated as guaranteed unassigned. Do not use it in a live payment, beneficiary-verification request, bank API, or production transfer flow. Keep synthetic IBANs inside isolated development and test environments.
Common IBAN testing mistakes
- Treating a checksum as account proof. MOD 97 detects many typing and transposition errors, but a passing result says nothing about account ownership, status, currency, or the bank's ability to receive a transfer.
- Testing only valid input. Add cases with a wrong country length, invalid characters, altered check digits, an unsupported country code, and an empty value. Each failure should produce a useful message rather than a generic error.
- Hard-coding one country's length. IBANs in this directory range from short national formats to values exceeding 30 characters. Form fields, database columns, masks, and mobile layouts must accept the full supported range.
- Validating the formatted display value. Users paste spaces, lowercase letters, and sometimes separators. Define one normalization policy, apply it before validation, and test that every supported paste format produces the same canonical electronic value.
- Using synthetic data in production. Keep test fixtures out of real beneficiary lists, payment queues, analytics samples, and screenshots that could be mistaken for transfer instructions. Use environment controls in addition to labels in the interface.
A practical payment-form test set
Start with one generated IBAN from each country your product supports. For every valid fixture, create a companion with one changed check digit and another with the wrong length. Test the electronic value without spaces, the grouped display value, lowercase input, paste behavior, and validation after editing in the middle of the field. Finally, verify that the application stores the normalized value, preserves leading zeroes, and never claims that checksum validation proves an account exists. That compact set covers the formatting, country-rule, and checksum failures most payment forms encounter.
You can send any generated fixture to the IBAN validator to inspect its country, length, BBAN structure, and MOD 97 result. For country-specific field definitions and examples, open the relevant IBAN country guide before encoding the same rules in your application.
IBAN generator FAQ
- Are generated IBANs real?
- No. Every value from this generator is a synthetic test fixture. It is designed to match a country's format and pass MOD 97, but it is not a bank account and must not be used to send or receive money.
- What is an IBAN number generator useful for?
- Developers use an IBAN number generator to test validation rules, payment forms, demos, and integration flows without exposing a real account number. Always label generated values as test data in your environment.
- Do generated IBANs pass validation?
- Yes. The generator follows the selected country's BBAN pattern and computes ISO 13616 MOD 97 check digits. Passing a checksum does not prove that an account exists.