Validate IBAN, ISBN, EAN/UPC and card numbers — and find the one wrong digit.

A check digit is arithmetic derived from the other digits in the number — it proves the number is internally consistent, nothing more. It cannot know whether that IBAN names an account that actually exists at the bank, whether that ISBN was ever assigned to a real book, or whether that card is active, unstolen, or has a balance. Those all require asking the bank, the ISBN registry (or a lookup like isbnsearch), or the card network — this tool only checks the syntax.

For ISBN-13, EAN-13, UPC-A, and Luhn, the check digit is a sum mod 10, and every digit position uses a weight of 1 or 3 — both coprime to 10 — over a 10-digit alphabet (0-9) that exactly covers all 10 possible remainders. That means whenever the checksum fails, there is usually a different digit at almost every position that would ALSO have made it pass. The math genuinely cannot narrow this down to "the" wrong digit from checksum alone — it can only do that reliably when the error is an adjacent transposition, which changes the sum in a way that is not generically repairable elsewhere. IBAN is the exception: mod 97 with only 10 possible digit values per position means a given position has roughly a 10% chance of admitting any fix at all, so a unique answer is common there.

IBANs and ISBNs are printed with spaces or hyphens between groups purely for readability (e.g. "DE89 3704 0044 0532 0130 00"), so this tool strips those two characters before checking. It will not silently strip anything else — a letter in a card number, for instance, is refused rather than dropped, because dropping it changes which digit is at which position and would make any "which digit is wrong" answer meaningless.

About 100 country and territory codes with their fixed total IBAN length, sourced from the SWIFT-derived IBAN registry published at iban.com/structure and checked in 2025. A country code missing from that table is refused outright rather than validated against a guessed length — the US, Canada, and Australia, for example, do not use IBAN at all.

No. The bank identifier is embedded in the BBAN portion of an IBAN at a country-specific position, but this tool only checks the overall MOD 97-10 checksum, not whether that particular bank code is assigned to a real institution. Use a BIC directory for that.

UPC-A (used mainly in the US and Canada) is 12 digits; EAN-13 (used almost everywhere else, and by GS1 generally) is 13. A UPC-A number is mathematically identical to an EAN-13 number with a leading zero, so this tool checks it the same way, but treats them as separate formats so the reported digit positions match what is actually printed on the barcode you are holding.

Yes — input is uppercased before checking, so "x" and "X" are treated the same. "X" is only a legal character in the final check-digit position; anywhere else it is refused, since it has no meaning as a data digit.

A run of 12 or 13 digits could legitimately be a UPC-A, an EAN-13, or the first part of a card number, and each format checks that string differently — a number that passes as one can fail as another. Guessing the format would silently pick a possibly-wrong answer, so the caller has to say which checksum applies.