IMEI check digit
The fourteen digits 49015420323751 get the check digit 8, giving the full IMEI 490154203237518. Complete a device number for a label or database, or check a fifteen-digit IMEI from a customer or scanner before you store it. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Number
- 49015420323751
- Calculation mode
- Compute
- Input
- 49015420323751
- Check digit
- 8
- With check
- 490154203237518
Every mobile handset and many cellular modules carry a fifteen-digit International Mobile Equipment Identity. The first fourteen digits identify the type allocation code and serial; the fifteenth is a Luhn check digit that catches single-digit typing errors and most adjacent transpositions before a number is stored, printed on a box, or sent to a carrier portal.
How the IMEI Luhn check digit is calculated
An IMEI is always fifteen decimal digits under the 3GPP numbering plan used for GSM, UMTS, LTE, and 5G equipment. The first eight digits form the type allocation code (TAC), the next six are a manufacturer serial within that TAC, and the fifteenth is the check digit. When twice a digit is greater than nine, subtract nine (equivalently, sum the tens and units digits of the product).
Add all fourteen weighted values; the check digit is (10 minus that sum modulo 10) modulo 10 so that the complete fifteen-digit number has a Luhn sum divisible by ten. Validation recomputes the expected digit from the first fourteen characters and compares it to the fifteenth, which is the same as running a full Luhn sum over all fifteen digits. The algorithm is deterministic and local: no TAC registry call, no clock, and no randomness.
Input contract, modes, and error behaviour
Send a number field that contains only characters zero through nine. Wrong length is an explicit error that names the mode and the length you sent—fourteen for compute, fifteen for validate—so client forms can show “need fourteen digits” without guessing. Empty strings, missing number, and invalid mode values fail before any Luhn sum runs and are not billed.
Prefer compute when you mint or complete device numbers for labels and databases; prefer validate when you gate a lookup, swap, or import on a full IMEI from a user, partner file, or scanner. Failed validation tasks that reject bad shape are not charged; a well-formed fifteen-digit string that simply has the wrong check digit returns valid false without throwing.
What you can do with it
Audit IMEI columns in device inventories
Batch-validate every fifteen-digit IMEI in an MDM, ERP, or RMA CSV and quarantine rows whose check digit no longer matches the recomputed expected value.
FAQ
What is an IMEI check digit?
It is the fifteenth digit of an IMEI, computed with the Luhn algorithm over the first fourteen digits so single-digit typing and scanning errors are usually caught before the number is stored or printed.
Is the IMEI check digit tool free?
The browser tool is free and runs locally.
What do the digits of an IMEI mean?
The first eight digits are the type allocation code, the next six are the manufacturer's serial number within that code, and the fifteenth is the check digit calculated from the other fourteen.
How is the IMEI check digit calculated?
Starting from the right, double every second digit of the fourteen, beginning with the rightmost, and subtract nine from any result above nine. Add everything up; the check digit is ten minus the remainder after dividing by ten, with ten becoming zero.
Does a valid IMEI mean the phone is registered or unlocked?
No. A correct check digit only shows that the fifteen digits were typed consistently. No manufacturer database is consulted, so it says nothing about whether the device is registered or unlocked.
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/imei \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"number":"49015420323751"}'const res = await fetch("https://api.kit.forhosting.com/enc/imei", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"number": "49015420323751"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/imei",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"number": "49015420323751"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/imei", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"number":"49015420323751"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"number":"49015420323751"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/imei", 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": "49015420323751"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.imei",
"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 implements that standard Luhn rule for IMEI only: compute mode accepts exactly fourteen payload digits and returns the check digit plus the full fifteen-digit string; validate mode accepts a full fifteen-digit IMEI and reports whether the trailing digit matches the recomputed expected value. Non-numeric input and wrong lengths fail with invalid_input instead of silent stripping, so you never persist a half-cleaned identifier. The same pure arithmetic runs free in the browser and at the published API price, with no network lookup of manufacturer databases and no claim that a valid checksum means the device is registered or unlocked.
How the IMEI Luhn check digit is calculated
To compute it, take the fourteen-digit payload and apply the Luhn algorithm from the right: double every second digit starting with the rightmost payload digit (because that digit sits in position two of the full fifteen-digit string when the check digit is position one from the right). Compared with generic card Luhn validators, the search intent here is narrow: people who need an IMEI check digit calculator for fourteen-digit payloads or a fifteen-digit mobile IMEI checker, not a payment card tool.
Input contract, modes, and error behaviour
Spaces, hyphens, letters, and decimal points are rejected as non-numeric input with invalid_input so a silently stripped value never reaches storage. Mode compute is the default: the engine requires exactly fourteen digits, returns check_digit as a one-character string, and returns with_check as the fifteen-digit IMEI you can print or persist. Mode validate requires exactly fifteen digits; the response reports valid true when the trailing digit matches the recomputed expected_check_digit, and always includes payload (the first fourteen digits), check_digit, expected_check_digit, and length fifteen. Alias keys such as digits, imei, and code are accepted for the same payload field so integrations that already speak “imei” do not need a rename. Because the path is pure parse with no clock, random source, or network, the same JSON body always yields the same JSON result on the free browser tool and on the API at $0.002 per successful request.
Where IMEI check digits fit real workflows
Device manufacturers and ODMs receive fourteen-digit internal serials and must append the official Luhn check digit before printing the IMEI on the box, SIM tray, or regulatory label. Carrier and MVNO portals validate fifteen-digit IMEIs at activation so a single transposition does not create a phantom device and a failed provisioning job. Asset-management and MDM systems walk every IMEI column in a CSV export, call validate mode, and quarantine rows where valid is false—catching both human edits and off-by-one bugs in generators. Repair shops and RMA desks recompute expected_check_digit when a customer reads the number over the phone, catching mistypes before a ticket is opened against the wrong handset. Do not treat a passing IMEI check as proof that the device is genuine, unlocked, or free of a carrier blacklist; it only proves the Luhn digit is consistent with the payload under the standard weights used for mobile equipment identity.
Integration use cases
Complete a 14-digit device number for labels
Call compute mode with the fourteen-digit payload, store with_check, and print the fifteen-digit IMEI on packaging, SIM trays, or regulatory labels.
Validate typed or scanned IMEI at entry
When a form, scanner, or partner file submits fifteen digits, 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 an IMEI check digit with this API?
POST with number set to exactly fourteen digits and mode compute (or omit mode). The response includes check_digit and with_check (the full fifteen-digit IMEI).
How do I validate a full fifteen-digit IMEI?
POST with the fifteen-digit string and mode validate. The response includes valid, check_digit, expected_check_digit, and payload (digits without the last one).
What happens with wrong length, letters, or hyphens?
Non-numeric input and lengths other than fourteen (compute) or fifteen (validate) are rejected with invalid_input. Failed validation tasks are not billed.