ISBN-10 to ISBN-13 converter
The ISBN-10 code 0306406152 becomes the ISBN-13 code 9780306406157: the prefix 978 is added and the check digit is recalculated, from 2 to 7. Paste either form, with or without hyphens, and get both back once the check digit is verified. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Isbn
- 0306406152
- Input
- 0306406152
- Input format
- isbn10
- Direction
- isbn10_to_isbn13
- Isbn10
- 0306406152
Publishers, booksellers, librarians, and catalogue systems still meet both ten-digit and thirteen-digit International Standard Book Numbers in the same workflow. An ISBN-10 identifies the same edition as its ISBN-13 counterpart that begins with 978, but the trailing check digit is not the same character: converting means validating the source code and recomputing the check digit for the target form. This capability accepts either format, strips optional hyphens and spaces, verifies the check digit, and returns both the ISBN-10 and ISBN-13 strings when conversion is possible.
How ISBN-10 and ISBN-13 relate and why the check digit changes
An International Standard Book Number identifies a specific book edition for trade, libraries, and retail systems. The older ISBN-10 form uses nine body digits plus a single check character that may be a digit or the letter X when the mod-eleven remainder is ten. The modern ISBN-13 form is a thirteen-digit GTIN-style number that for book trade almost always starts with the GS1 bookland prefix 978 or 979 and ends with an EAN-style check digit computed from alternating weights of one and three.
When an ISBN-10 is rewritten as ISBN-13 under the 978 prefix, the nine body digits are preserved and three leading nines-seven-eight are added, but the old check character is discarded and a new thirteenth digit is computed over the twelve data digits. The reverse path drops the 978 prefix, keeps the next nine digits, and recomputes the ISBN-10 check character with the classic weighted sum modulo eleven.
Prefix 979 ISBN-13 codes are valid book numbers under the ISBN-13 rules, yet they have no corresponding ISBN-10 form, so a converter must refuse that direction rather than invent a ten-digit string.
Where an ISBN converter fits real catalogue workflows
Bookstore point-of-sale systems often scan a thirteen-digit barcode while older inventory rows still store the ten-digit form; converting both ways with check-digit validation catches mistyped imports before they create duplicate SKUs. Marketplace listing tools that accept either format can normalize every title to ISBN-13 for channel submission while still showing the legacy ISBN-10 that appears on older covers and CIP blocks. Library migration scripts re-key large MARC or spreadsheet exports and need a deterministic oracle that rejects bad check digits instead of padding zeros.
Publishing operations that mint codes under a GS1 company prefix already know the twelve data digits and still benefit from a small converter when integrating partner feeds that mix hyphenated ISBN-10 with compact ISBN-13. Do not treat a successful conversion as proof of registry ownership or that the book is in print — it only proves the two strings are arithmetically consistent under the ISBN-10 and ISBN-13 check rules.
What you can do with it
Normalize mixed catalogue imports
Accept hyphenated ISBN-10 or compact ISBN-13 from a CSV, convert to both forms with validated check digits, and store a single canonical pair per edition.
Marketplace and POS dual display
Show the thirteen-digit barcode value for scanning while still printing the classic ten-digit ISBN on invoices and older label templates.
Data-quality gates before publish
Reject rows whose ISBN fails its check digit or uses a 979 prefix when a downstream system still requires ISBN-10.
FAQ
How do I convert ISBN-10 to ISBN-13?
Send the ten-character ISBN-10 (hyphens optional) in the isbn field.
How do I convert ISBN-13 back to ISBN-10?
Send a thirteen-digit ISBN-13 that starts with 978.
Why does a 979 ISBN-13 fail conversion to ISBN-10?
Prefix 979 book numbers have no ISBN-10 equivalent under the standard mapping.
Are hyphens and spaces allowed?
Yes. Common separators are stripped before validation. Other letters (except a trailing X on ISBN-10) and wrong lengths are rejected as malformed.
Why does the last digit change when I convert?
Because each format has its own check rule. ISBN-10 uses a weighted sum modulo 11, while ISBN-13 uses alternating weights of 1 and 3 modulo 10, so the old check character is dropped and a new one is calculated.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/enc/isbn-convert \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"isbn":"0306406152"}'const res = await fetch("https://api.kit.forhosting.com/enc/isbn-convert", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"isbn": "0306406152"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/isbn-convert",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"isbn": "0306406152"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/isbn-convert", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"isbn":"0306406152"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"isbn":"0306406152"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/isbn-convert", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"isbn": "0306406152"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.isbn_convert",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Codes that are too short, too long, non-numeric where digits are required, or that fail their check digit are rejected with invalid_input instead of a silent guess. Run it free in the browser or call the KIT API at the published price; both paths use the same pure arithmetic with no network lookup of title metadata.
How ISBN-10 and ISBN-13 relate and why the check digit changes
This endpoint encodes exactly those rules: it does not fetch titles, publishers, or registry metadata, and it never invents a check digit that would make an invalid source look valid.
Input contract, response shape, and error behaviour
The value may include spaces or hyphens for human-readable presentation; those separators are stripped before length and check-digit checks. POST a JSON body with a required isbn field (aliases include number, code, text, and value). After normalization, a ten-character string matching nine digits plus a digit or X is treated as ISBN-10: the engine validates the check character, builds the twelve-digit payload 978 plus the nine body digits, appends the ISBN-13 check digit, and returns both forms with direction isbn10_to_isbn13. A thirteen-digit string is treated as ISBN-13: the EAN check digit is validated, the prefix must be 978 or 979, and only the 978 case converts to ISBN-10 with direction isbn13_to_isbn10. Success payloads always include input (normalized), input_format, direction, isbn10, isbn13, check_digit_isbn10, check_digit_isbn13, and prefix. Empty strings, wrong lengths, letters other than a trailing X on ISBN-10, a wrong check digit, a non-bookland thirteen-digit code, and a 979-prefix request to produce ISBN-10 all fail with invalid_input and are not billed. Because the path is pure parse with no clock, random source, or network, the same input always yields the same JSON on the free browser tool and on the API at $0.002 per successful request.
Where an ISBN converter fits real catalogue workflows
In every workflow the contract is the same: one isbn string, auto-detected direction, structured JSON you can pin in tests, identical behavior free in the browser or via prepaid KIT balance, and honest failure when the string is not a well-formed convertible ISBN.
Technical questions
What does the ISBN converter cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid or malformed input is not billed.