Barcode check digit

System picks from ean8, ean13, upca, gtin14, isbn13, isbn10 or luhn. The first four plus isbn13 share the same GTIN weighting, alternating 3 and 1 from the digit next to the check digit. isbn10 uses its own mod 11 weighting, and luhn is the classic doubling scheme used by credit card and IMEI numbers.

compute takes a code with no check digit yet and works out what it should be, then prints the full code. verify takes a code that already ends in its check digit and reports whether that digit is correct, naming the expected digit when it is wrong.

Because you asked for isbn10 and the mod 11 remainder came out to 10. ISBN-10 is the one system here where the check character is not always a digit, and a remainder of 10 is written as the letter X rather than as two digits.

No. Spaces and hyphens are stripped from the text before anything is checked, so 978-0-13-468599-1 and 9780134685991 are treated identically. What is left after that has to be plain digits, or digits plus a trailing X for isbn10.

It refuses and names both counts: how many digits your code had and how many the chosen system needs, for example an ean13 verify with 12 digits instead of 13. compute and verify expect different lengths, since verify includes the check digit and compute does not.

No. It has no browser-only restriction, so it runs the same way on the command line, through MCP, or on the page.