Skip to content
CardTools

Card number tools: PAN, Luhn, track and ARN

Card numbers carry more structure than they look like they do: an issuer prefix, a scheme range, a check digit, and in track data a service code that says how the card may be used. These tools pull that apart. Everything runs locally, which matters more here than anywhere else on the site.

What a PAN tells you, and what it does not

A PAN passing Luhn means one thing: the digits are internally consistent. It does not mean the number was ever issued, that an account stands behind it, or that the card is live. Luhn catches transposed digits and typos, which is what it was designed for in 1954 and the whole of what it does.

The leading digits identify the scheme and, within it, the issuer. The industry moved from six-digit BINs to eight-digit issuer identifiers, and both are still in circulation, so any range table has overlaps in it. The PAN validator reports the ranges a number matches rather than picking one and sounding confident about it.

Nothing here tells you whether a card is debit or credit, prepaid or commercial, or which country issued it. Those come from a commercial BIN database that is licensed and updated, not from the number itself.

Track data carries more than the number

Track 2 holds the PAN, the expiry date and a three-digit service code, separated by sentinels. Chip cards carry the same structure in tag 57 and tag 9F6B, which is why a track parser is as useful on a chip trace as on a stripe read.

The service code is the part people skip and the part that matters. Its first digit says whether the card is international or chip-capable, the second says who authorises it, and the third says whether a PIN is required and whether use is restricted to goods and services. A card whose service code starts 2 or 6 has a chip, and a stripe read of one is a fallback that your acquirer will price accordingly.

Why this category runs locally

Every tool on this site runs in your browser, and on this page it is the point rather than a nicety. A PAN, a track read or an expiry date is cardholder data, and pasting it into a website that posts it to a server is the thing PCI DSS exists to prevent.

There is no backend here to send anything to, and the content security policy blocks the browser from making outbound requests at all. The privacy page shows you how to confirm that in devtools rather than asking you to take it on trust. Use test numbers where you can, and where you cannot, at least you can see where the data goes.

Not built yet

  • Test Card Numbers. The officially published test numbers, by scheme and by gateway, plus a generator for your own BIN.

The other categories