ISBN-10 and ISBN-13 conversion

The ISBN barcode generator accepts an ISBN-10 or an ISBN-13 and renders an EAN-13 symbol carrying the thirteen-digit form. This guide walks through what the verification layer does on the way: verifying the ISBN-10 mod-11 check, converting a valid ISBN-10 to a 978 ISBN-13, offering or refusing the reverse conversion, and the notes and errors that result. Every figure is computed at build time by the functions that run in your browser, on published reference values cited in this site's test files or on numbers invented here and labelled as such.

Two check systems, one number

An ISBN-10 and its ISBN-13 form identify the same book under different arithmetic. ISBN-10 uses a mod-11 check: weights 10 through 2 over the nine data digits, the check character carrying weight 1, and the weighted sum required to divide by 11 — which is why the check character is sometimes X. An ISBN-13 is an EAN-13 number (the validator hands it to the renderer as an EAN-13 payload), so it carries the GTIN mod-10 check instead, weights 3 and 1 anchored at the rightmost data digit, as worked through in How GTIN check digits are computed. The two checks share only the nine data digits they protect, so converting between the forms always means dropping one check character and computing another. The validator recognises 978 and 979 as the Bookland EAN prefixes, and the breakdown engine in EAN-13 structure explained classifies both as isbn and guesses nothing further.

The mod-11 check, worked on a cited vector

Take the published ISBN-10 example 0-306-40615-2. Normalisation strips the hyphens, giving 0306406152. Multiply each data digit by its weight, 10 down to 2, and add the products:

The check character brings the weighted sum up to the next multiple of 11. The vector ends in 2, the engine expects 2, and verifyIsbn10 reports it valid. The X vector below shows the remainder-1 case: the required value is 10, written X.

When the answer is ten

The second published vector, 0-8044-2957-x — typed with a lowercase x on purpose — normalises to 080442957X. Its weighted sum is 199 (0×10 + 8×9 + 0×8 + 4×7 + 4×6 + 2×5 + 9×4 + 5×3 + 7×2), the remainder is 1, the required value is 10, and since one character cannot hold ten the engine writes X. The uppercase conversion happened in normalisation, before any arithmetic. X is accepted only in the final position — the shape rule is nine digits plus one character that is a digit or X — so an X anywhere else is rejected as malformed, not treated as a wrong check.

ISBN-10 to ISBN-13: verify, prefix, recompute

isbn10To13 does three things in a fixed order. It verifies the ISBN-10's own check character — a mistyped ISBN-10 is never converted, because converting it would turn a detectable error into a structurally valid ISBN-13 for the wrong book. It prefixes 978 to the nine data digits. It computes the EAN-13 check digit over those twelve digits with the EAN-13 generator's mod-10 arithmetic.

The ISBN-10 ended in 2; the ISBN-13 ends in 7. Nothing was carried across: the new final digit is a fresh computation under a different modulus, and when it matches the old one that is coincidence. The X example converts the same way, 080442957X → 9780804429573; the X disappears because a mod-10 check never needs the value ten.

ISBN-13 to ISBN-10: 978 only

The reverse direction exists under three conditions, checked in a fixed order. isbn13To10 first requires exactly thirteen digits, then verifies the ISBN-13's mod-10 check digit — a number that fails its own check is refused before any conversion — and then requires the 978 prefix. For a 978 number it drops the prefix, keeps the nine data digits and computes the mod-11 check character: 9780306406157 → 0306406152, the vector this guide started with; the X example round-trips too, 9780804429573 → 080442957X.

A 979 ISBN-13 has no ISBN-10 form, and the engine says so instead of inventing one. Take the fictional number 9798124609353: the nine digits after the prefix are invented, and its check digit 3 was computed by ean13CheckDigit so the refusal concerns the prefix, not the arithmetic. Asked for its ISBN-10, isbn13To10 answers:

In the generator the same number is accepted and renders normally; its notes read: ISBN-13 9798124609353 verified: the check digit 3 matches its first 12 digits. 979-prefixed ISBNs have no ISBN-10 equivalent. That is the methodology's condition made visible: the reverse conversion "exists for 978 ISBNs and is explicitly refused for 979".

How to read the notes

Every accepted input comes back with notes stating what validation did — which check character or digit was verified, which was computed, and which conversion was performed — written on the normalised number: hyphens and spaces are stripped and a trailing x uppercased before the note is composed, so the note shows the normalised form rather than announcing the stripping.

• ISBN-10 input 0-306-40615-2: ISBN-10 0306406152 verified (check character 2), then converted to ISBN-13 9780306406157: 978 prefix + your 9 data digits + recomputed EAN-13 check digit 7. The payload is 9780306406157 and the check digit is in computed mode: the ISBN-13's final digit was derived here, not typed by you.
• ISBN-13 input 978-0-306-40615-7: ISBN-13 9780306406157 verified: the check digit 7 matches its first 12 digits. Its ISBN-10 form is 0306406152. The check digit is in verified mode — you supplied it and it checked out. The ISBN-10 form is information only; the payload stays the ISBN-13.
• The lowercase-x vector 0-8044-2957-x: ISBN-10 080442957X verified (check character X), then converted to ISBN-13 9780804429573: 978 prefix + your 9 data digits + recomputed EAN-13 check digit 3. The uppercase X is in place before the note is written.

How to read the errors

Check errors name the expected value and leave your input alone; shape and prefix errors state the rule that was not met. Change the fifth character of the cited vector to make 0306706152, a number invented for this guide. verifyIsbn10 reports expected 6 against supplied 2 and marks it invalid; isbn10To13 refuses:

Notice what the error does not do: it does not swap the final character for 6 and carry on. The mistake was in the data, not the check, so a repaired number would be internally consistent — and could be someone else's ISBN; a mismatch is evidence of a typo somewhere in the ten characters, and only you know where. Swapping two adjacent digits of the same vector gives 0360406152; the validator reports it invalid, expected 7 against supplied 2.

The other refusals follow the pattern. An ISBN-13 with an altered check digit, 9780306406158, produces: ISBN-13 check failed: the final digit must be 7, but you entered 8. Check the number for a typo. A thirteen-digit number outside 978 and 979 is not an ISBN at all — the published EAN-13 sample 5901234123457 gets: An ISBN-13 starts with 978 or 979 (the Bookland EAN prefixes). This number starts with 590, so it is not an ISBN — use the EAN-13 generator for general retail numbers. An incomplete entry such as 978030640615 gets the shape rule: Enter a complete ISBN-10 (10 characters, final may be X) or ISBN-13 (13 digits), with or without hyphens.

Where the arithmetic stops

• Symbols, not numbers. Rendering an ISBN barcode does not register an ISBN; national ISBN agencies do that. A verified check means the characters are internally consistent, nothing more; this site cannot know whether a number has been issued. For retail GTINs, see Do I need a GS1 barcode?
• Math, not optics. The conversion and both checks are arithmetic over the characters you typed. Whether a printed cover scans depends on contrast, size, substrate and preserved quiet zones, which no browser can certify — test a production sample with your own scanner. The verifier and its guide cover what the independent decoder does check on screen.
• Hyphens are not validated. normalizeIsbn strips spaces and hyphens without checking where they fell; the validator judges the characters, not the hyphenation.
• No EAN-5 add-on. The generator renders the main Bookland EAN only; the omission is deliberate and stated on the tool page.

Common misreadings

• "The ISBN-13 is the ISBN-10 with 978 in front." Almost: the nine data digits are kept, but the final character is recomputed under a different modulus.
• "The tool corrected my check digit." It never does. The only computed check digit on the ISBN path is the EAN-13 digit of a converted ISBN-10, and the note says so.
• "Valid means registered." Valid means internally consistent; registration is a national ISBN agency's record, not a property of the digits.

ISBN conversion FAQ

Related tools and guides

• ISBN barcode generator — the tool this guide explains.
• EAN-13 generator and check digit calculator — mod-10 in compute and verify mode.
• How GTIN check digits are computed — the mod-10 walk-through in depth.
• EAN-13 structure explained — the breakdown engine's reading of thirteen digits.
• All guides.

Math, not optics: this guide describes how check characters and conversions are verified, not whether a printed symbol will scan — test a production sample with your own scanner. See the methodology page for the full boundary.