Luhn mod-10 check digit
For 7992739871 the Luhn check digit is 3, giving 79927398713: the same mod-10 rule payment cards use, applied to any string of digits such as loyalty IDs, warehouse codes or serials. Validate mode checks a number that already ends in its digit. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Number
- 7992739871
- Calculation mode
- Compute
- Input
- 7992739871
- Check digit
- 3
- With check
- 79927398713
Long account codes, IMEI fragments, membership numbers, and internal serials are easy to mistype. The Luhn algorithm — also called the mod-10 check digit scheme — appends a single trailing digit so that most single-digit substitutions and many adjacent transpositions break the checksum. Unlike a payment-card-only checker, it accepts any length of digits so you can protect warehouse SKUs, loyalty IDs, and batch labels with the same rule the industry already trusts on cards.
What the Luhn mod-10 algorithm does and what it catches
Check digits exist because people and keyboards introduce predictable damage: one wrong key, two neighboring digits swapped, or a digit inserted or dropped during re-keying. Hans Peter Luhn published a simple right-to-left procedure that doubles every second digit, reduces values above nine by subtracting nine, sums the result, and chooses a trailing digit so the total is divisible by ten. That construction catches all single-digit errors and most adjacent transpositions, which is why payment networks, telecom identifiers, and countless internal account formats still rely on it decades later.
This tool implements that standard walk on any pure digit string — not a house variant and not a card-network BIN parser. The response always names the algorithm as luhn so downstream systems can record which scheme protected the value. Knowing those trade-offs helps you pick the right scheme: use Luhn when interoperability with existing mod-10 systems matters more than catching every last transposition pair.
Where Luhn check digits fit real systems
Membership and loyalty programs mint sequential or random numeric IDs and need a trailing digit that call-center agents and mobile keyboards will not silently corrupt. Warehouse and logistics teams print carton or asset codes; a single mistyped digit on a handheld path is common, and Luhn catches every single-digit substitution. Telecom and device workflows that already document IMEI or similar identifiers in mod-10 form can recompute and verify without a card-specific UI.
Integration tests and data-quality jobs recompute the expected check digit for every row in a CSV export and flag rows where the stored full number no longer matches, which catches both human edits and off-by-one bugs in generators. Product teams that already expose a card Luhn validator for payment UX can still adopt this general tool for internal identifiers where the same algorithm is required but the input is not a PAN.
Do not treat a passing Luhn check as proof of authorization, ownership, or that a card is real — it only proves the digit string is well formed under this algorithm, the same honesty bar you apply to any checksum.
What you can do with it
Audit exported ID columns
Batch-validate every numeric ID in a partner CSV or warehouse export and quarantine rows whose check digit no longer matches the recomputed expected value.
FAQ
What is a Luhn mod-10 check digit?
It is a single trailing digit computed with Hans Peter Luhn’s doubling algorithm so that the full number’s weighted digit sum is divisible by ten, catching most single-digit and many transposition typos.
What happens with letters, spaces, or hyphens?
Provide digits 0-9 only; failed validation tasks are not billed.
Is the Luhn check digit tool free?
The browser tool is free and runs locally.
Which typing mistakes does the Luhn check digit catch?
It catches every single wrong digit and most swaps of two neighboring digits, the two slips people make most often when re-keying a number. A few swaps get through, which is the trade-off for staying compatible with existing mod-10 systems.
Does a valid Luhn number mean a card or account is real?
No. A passing check only shows that the digit string is well formed under the Luhn rule. It proves nothing about authorization, ownership or whether a card exists, so treat it as a typo filter, not as verification.
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/luhn \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"number":"7992739871"}'const res = await fetch("https://api.kit.forhosting.com/enc/luhn", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"number": "7992739871"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/luhn",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"number": "7992739871"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/luhn", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"number":"7992739871"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"number":"7992739871"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/luhn", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"number": "7992739871"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.luhn",
"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
This capability computes that digit for any pure digit payload you already have, or validates a complete number that already includes one, and it rejects non-numeric input with a clear error instead of silently stripping hyphens or letters. 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 and no stored numbers.
What the Luhn mod-10 algorithm does and what it catches
You get the check digit as a one-character string, the full number with the digit appended, or a boolean validity flag with the expected check digit recomputed from the payload alone. Compared with Damm quasigroup check digits, Luhn is the de-facto industry default for card-like and account-like fields; compared with barcode family check digits (EAN, UPC, ISBN), Luhn is not tied to a retail GTIN layout — it applies to any digit payload you choose.
How to compute a check digit or validate a full number
Send a number field that contains only characters 0 through 9. Empty strings, missing number, and invalid mode values fail before any doubling runs and are not billed. Spaces, hyphens, letters, decimal points, and scientific notation are rejected as non-numeric input with invalid_input so you never accept a silently stripped value. Mode compute is the default: the engine walks the payload from the right as if a check digit will sit at the end, returns check_digit as a one-character string, and returns with_check as the payload plus that digit so you can store or print a single string. Mode validate expects a full number of at least two digits (one or more payload digits plus the trailing check digit). The response reports valid true when the full weighted sum is divisible by ten, and always includes the trailing check_digit, the expected_check_digit recomputed from the payload alone, and the payload substring without the last digit. That shape makes it easy to show “you typed X, expected Y” in a form without a second call. 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 you can protect bulk imports, onboarding forms, and batch label printers without negotiating a custom tier. Prefer compute when you mint new IDs; prefer validate when you receive an ID from a user, a partner file, or a scanned label and need a boolean gate before looking up the record.
Integration use cases
Mint membership or account IDs
Generate a sequential payload, call compute mode, and store with_check so every new ID carries a Luhn trailing digit before it is printed on cards or emailed to members.
Validate typed or scanned codes at entry
When a user or scanner submits a full number, call validate mode and block lookup when valid is false, showing expected_check_digit to help correct a single mistype.
Technical questions
How do I compute a Luhn check digit with this API?
POST with number set to the payload digits and mode compute (or omit mode). The response includes check_digit and with_check (payload plus check digit).
How do I validate a number that already has a check digit?
POST with the full digit string and mode validate. The response includes valid, check_digit, expected_check_digit, and payload without the last digit.