Checksum Validator

Features

• ⚠️ The first line says a passing checksum does not mean the number exists, and every verdict reads “checksum passes” rather than “valid”
• Bank cards: Luhn plus issuer identification from the IIN range, with a separate flag when the range and the length disagree
• IBAN: ISO 7064 MOD 97-10, tolerating spaces and lowercase; country lengths vary (Norway 15, Malta 31) and all are handled
• ISBN-10 (with X as 10), ISBN-13 / EAN-13 and UPC-A, with the 978/979 prefix called out as a book
• ABA routing numbers (3-7-1 weighting), noting that passing only means the algorithm is satisfied, not that the bank exists
• BIC / SWIFT: format only — it has no check digit, and the verdict says so
• Bitcoin addresses told apart into Legacy (`1`, P2PKH), P2SH (`3`, multisig / nested SegWit), SegWit v0 (`bc1q`) and Taproot (`bc1p`), with a note that the types are not interchangeable
• Bitcoin checksums try both the Bech32 and Bech32m constants and say which matched; a valid-looking address with a broken checksum is failed
• Ethereum: EIP-55 case checksum using Keccak-256; an all-lowercase or all-uppercase address is reported as “cannot be checked”, never as failing
• ⚠️ One input can belong to several systems at once (both 9-digit and 13-digit numbers do), so the result is a list, not a single verdict
• Paste several values, one per line, grouped per line

How to use

1. Paste the numbers, one per line
2. Read the verdict: passes / fails / format only / cannot be checked
3. Read the basis line to see which algorithm decided it

FAQ

If it passes, is the card number real?

No. A check digit catches typing errors: a dropped digit, two digits transposed, a slipped keypress — Luhn catches about nine in ten of those. It does nothing against invention: anyone making up a card number computes the Luhn digit, which is one division. So “passes” means only “no obvious copying mistake”, and says nothing about whether the card exists, whose it is, or whether it works.

Why does Ethereum use Keccak-256 rather than SHA3-256?

Because Ethereum predates the SHA-3 standard. The two differ only in the first padding byte (original Keccak uses `0x01`, NIST SHA-3 uses `0x06`) and produce completely different output. Computing EIP-55 checksums with SHA3-256 makes every correct address fail — and both look like “a hash”, so nothing errors. The three example addresses from the EIP-55 specification pin this down in the tests.

Why is an all-lowercase Ethereum address “cannot be checked”?

Because the EIP-55 checksum is carried in the capitalisation: after hashing with Keccak-256, a hex digit of 8 or above means the corresponding address character is uppercased. So an all-lowercase or all-uppercase address carries no checksum information at all — and both forms were legal before EIP-55, with plenty of tools still emitting them. Reporting “fails” would suggest the address is wrong; “cannot be checked” is the truth.

Why does BIC only get “format correct”?

Because BIC has no check digit. It is four characters of institution code, two of country, two of location and an optional three of branch — all looked-up alphanumerics with nothing for self-verification. So the tool can check length and that the country code is letters, but not whether the code exists; the verdict says so, so “format correct” is not mistaken for “verified”.

What do the `1`, `3`, `bc1q` and `bc1p` Bitcoin address prefixes mean? Are they interchangeable?

They are four generations of address format, signed differently and not mutually compatible. `1` is Legacy (P2PKH), the oldest; `3` is P2SH (pay-to-script-hash, common for multisig and nested SegWit); `bc1q` is SegWit v0 (P2WPKH / P2WSH); `bc1p` is Taproot (SegWit v1). Each passes its own checksum — the Base58 pair via the version byte (`0x00` / `0x05`) plus a four-byte double-SHA-256 checksum, the bech32 pair via the Bech32 / Bech32m checksum (identical except for the final XOR constant). ⚠️ They are not interchangeable: handing a `1` or `3` address to an exchange that only accepts bech32 gets rejected outright, and vice versa — so use whichever generation the recipient supports.