IBAN Format and Checksum Checker

How to use IBAN Format and Checksum Checker

Before copying account details into another workflow, inspect the source spelling, country-specific character positions and international checksum. This checker keeps malformed and unsupported rows visible beside passing rows, with an explicit space policy and a local download. A passing source check never proves that an account exists or belongs to the intended recipient.

1. Paste the exact original strings, one per line, or select a strict UTF-8 text file. Start with bank-issued details; do not guess missing characters or zeros.
2. Choose whether ASCII spaces may be removed. Both modes explicitly uppercase ASCII lowercase letters; tabs, nonbreaking spaces and Unicode lookalikes are never substituted.
3. Run the source check. Review national length and BBAN character-class results separately from the exact MOD97 remainder and the selected check-digit profile.
4. Resolve unsupported countries or check-digit profiles with the issuer. Keep every malformed row visible; passing rows establish only the listed source checks.
5. Download JSON for complete per-line evidence or CSV for a table. Check original versus normalized spellings before sharing or using bank details elsewhere.

Good to know

• This checker pins 89 national BBAN format profiles from SWIFT IBAN Registry release 103, September 2026. It performs no live registry update. A country missing from that snapshot is unsupported, not declared invalid. It does not infer other territory prefixes or apply national/local bank checksum algorithms.
• A selected-checks pass requires the pinned national length and digit/letter/alphanumeric positions, check digits in the selected generated range 02–98, and MOD97 remainder 1. Values 00, 01 and 99 are explicitly outside this checker's selected profile, even if a remainder happens to be 1. They are reported for issuer review, not repaired or certified invalid accounts.
• No account existence, bank identity, recipient name, ownership, routing, payment ability, fraud detection, legal compliance or issuer authorization is checked. No money moves, account connection, IBAN generation, domestic-account conversion, replacement check digits or automatic correction is provided.
• Use 1–200 original lines and at most 80 UTF-16 code units per line, within a 20,000-character source cap. One terminal LF or CRLF is treated as a delimiter; other blank lines and duplicates remain as separate source rows. Ordinary malformed IBANs produce row diagnostics. Row/count/source/control budget violations refuse the entire batch.
• A selected file must be strict UTF-8, 1–50,000 bytes, with at most one initial BOM. The file takes precedence over pasted text. Bare CR, malformed Unicode, NUL, DEL and other disallowed controls refuse the source. Tabs and non-ASCII source characters remain invalid row data; they are not whitespace normalization.
• Allow ASCII spaces removes only U+0020, including leading, trailing or repeated spaces, then creates a canonical four-character display grouping. Electronic only refuses spaces. Both modes uppercase ASCII letters after the ASCII-only character gate and report that change. These are explicit presentation transformations, not account corrections.
• All arithmetic uses exact small integer remainders; no full IBAN is converted to a JavaScript Number. Complete JSON and CSV are each capped at 1,000,000 characters. CSV quotes every cell and prefixes formula-like original text with an apostrophe; JSON preserves the original strings. Downloads contain the entered details and should be handled accordingly.
• Processing stays in this tab without uploads, persistence, external resources, account registration or code execution. The downloaded source report is evidence for review, not a bank-issued identifier or an approval to send money.