IMEI Generator
Generate 15-digit, Luhn-valid test IMEI numbers for device forms, QA fixtures and sample data — with the structure and checksum explained. Fictional identifiers only: they are not assigned to real devices and must never be used for unlocks, warranty claims or blacklist lookups.
Updated
In short
An IMEI is a 15-digit device identifier made of an 8-digit Type Allocation Code, a 6-digit serial number and a final Luhn check digit. This generator produces values with a correct check digit for testing, using a reserved test TAC so they are not assigned to any real device.
- Digits 1–8 are the Type Allocation Code (TAC), which identifies the device model; the first two are the Reporting Body Identifier that issued it.
- Digits 9–14 are the serial number, unique within that TAC.
- Digit 15 is a Luhn (mod-10) check digit computed over the preceding 14 digits.
- Generated values pass length and Luhn validation, and are correctly rejected by any system that verifies the TAC against the real GSMA allocation database.
- Every value uses a reserved test TAC rather than a real manufacturer's, so it cannot be mistaken for a specific physical handset.
- Never use a generated IMEI for carrier registration, device unlocking, warranty claims, blacklist or stolen-device lookups, resale listings or KYC.
004999010990231004999019665966004999013089304
This IMEI generator creates 15-digit test identifiers that follow the real IMEI structure defined in 3GPP TS 23.003: an 8-digit Type Allocation Code, a 6-digit serial number, and a Luhn check digit that makes the whole string self-verifying. Because the checksum is computed rather than faked, the values pass the format and check-digit validation almost every input field runs — which is exactly what you need when the thing under test is your own validation code.
The practical use is filling a device field without copying a real phone's identifier out of a settings screen. A real IMEI is a hardware identifier tied to a physical handset, and pasting one into a bug report, a screenshot, a seeded database or a public test fixture leaks it. A generated value looks and validates the same, belongs to nobody, and is safe to commit.
Use generated IMEI numbers for software testing, QA fixtures, form-validation tests, screenshots, demos and documentation examples. Do not use them for carrier registration, device unlocks, warranty claims, blacklist or stolen-device lookups, resale records, insurance claims, KYC or any workflow that requires a real device identifier. Those systems check the TAC against the GSMA allocation database and a test value will not — and should not — clear them.
Pick how many you need and press Generate. Each value is free, instant, copyable individually or in bulk, and downloadable as CSV or JSON. If you need a complete fictional person with a matching address, phone and email, use the full identity generator instead.
How a test IMEI is structured
| Part | Position | Digits | What it means | Generator behaviour |
|---|---|---|---|---|
| Reporting Body Identifier (RBI) | 1–2 | 2 | Which GSMA reporting body issued the TAC | Part of the fixed test TAC |
| Type Allocation Code (TAC) | 1–8 | 8 | Identifies the device model, assigned by the GSMA | Fixed to a reserved test value, never a real model |
| Serial number (SNR) | 9–14 | 6 | Distinguishes individual units within one TAC | Derived from the seed, so it varies per value |
| Check digit (CD) | 15 | 1 | Luhn mod-10 checksum over the first 14 digits | Computed, so every value is genuinely self-consistent |
| Total | 1–15 | 15 | Digits only, no separators | Ready to paste into a form or fixture |
Generated values are format-valid sample data. They are not assigned to real devices and should never be used as real hardware identifiers.
How the Luhn check digit is calculated
The final digit of an IMEI is not data — it is a checksum over the other fourteen, using the same Luhn mod-10 algorithm that validates credit-card numbers. Its job is to catch the two mistakes humans actually make when copying long digit strings: a single mistyped digit, and two adjacent digits swapped. Both change the checksum, so both are caught immediately without any lookup.
The rule is: walking right to left across the fourteen digits, double every second one starting with the digit immediately left of the check position. If doubling produces a two-digit result, subtract nine. Add every resulting value. The check digit is whatever must be added to reach the next multiple of ten — that is, (10 − sum mod 10) mod 10.
The table below is computed live from the first value this page generated, not written by hand, so it always matches what the tool actually produced. Note the practical consequence for testing: because only one digit in ten satisfies the checksum, a randomly typed 15-digit string has a 90% chance of being rejected. That makes the Luhn check a genuinely useful first-line filter, and it makes a generator that computes the digit correctly worth using over one that pads random numbers.
Worked example: 004999010990231
Taking the first value this page generated, the check digit is derived from its 14-digit body 00499901099023. Every second digit from the right is doubled, and any doubled result above nine has nine subtracted from it.
| Position | Digit | Doubled? | Contributes |
|---|---|---|---|
| 1 | 0 | no | 0 |
| 2 | 0 | yes | 0 |
| 3 | 4 | no | 4 |
| 4 | 9 | yes | 9 |
| 5 | 9 | no | 9 |
| 6 | 9 | yes | 9 |
| 7 | 0 | no | 0 |
| 8 | 1 | yes | 2 |
| 9 | 0 | no | 0 |
| 10 | 9 | yes | 9 |
| 11 | 9 | no | 9 |
| 12 | 0 | yes | 0 |
| 13 | 2 | no | 2 |
| 14 | 3 | yes | 6 |
The contributions total 59. The next multiple of ten is 60, so the check digit is (10 − 59 mod 10) mod 10 = 1 — which is the final digit of 004999010990231.
To verify any IMEI by hand, run the same doubling pattern across all fifteen digits instead of fourteen: if the total is a multiple of ten, the number is Luhn-valid. Changing any single digit, or swapping two adjacent ones, breaks that property — which is the whole reason the check digit exists.
Why these values use a reserved test TAC
The Type Allocation Code is issued by the GSMA to a specific device model. That makes it the one part of an IMEI that carries real-world meaning: given a TAC, you can look up the manufacturer and the model. A generator that rotated through real manufacturers' TACs would therefore emit values that appear to identify a particular physical handset — which is precisely the confusion that makes fake device identifiers risky rather than useful.
So this generator holds the TAC fixed at a long-standing reserved test value and varies only the serial portion. The result is unambiguous: the format is right, the checksum is right, and the model prefix announces itself as test data to anyone who looks it up. Systems that validate structure will accept it; systems that validate allocation will reject it. That split is the correct behaviour for test data, and it is what you should assert in your own tests.
It also means the values are stable to reason about. If your test suite needs to distinguish 'a well-formed IMEI' from 'an IMEI belonging to a device we support', the fixed test TAC gives you a reliable negative case for the second check.
Using test IMEI numbers in automated tests
For unit and integration tests, generate the values once and commit them rather than calling a generator at test time — a fixture that changes between runs turns a deterministic assertion into a flaky one. Every value on this page is reproducible: the free API accepts a seed parameter and returns byte-identical IMEIs for the same seed, so a committed fixture and a live call can be kept in sync.
Three cases are worth covering explicitly, and a generator only helps with the first: a valid IMEI that should be accepted; a 15-digit string with a deliberately wrong final digit, which your Luhn check must reject; and a 14- or 16-digit string, which your length check must reject before the checksum runs at all. Build the second case by taking any generated value and incrementing its last digit.
For load and volume testing, request a batch instead of looping: this page generates up to 100 at once with CSV and JSON download, and the API returns up to 1,000 per call because IMEI generation is pure arithmetic with no locale data behind it.
IMEI vs the other device identifiers people confuse it with
| Identifier | Length | Used by | Check digit |
|---|---|---|---|
| IMEI | 15 digits | GSM, UMTS and LTE handsets | Yes — Luhn mod-10 |
| IMEISV | 16 digits | IMEI with a 2-digit software version, replacing the check digit | No |
| MEID | 14 hex characters | CDMA devices | Yes, but a different scheme |
| ESN | 8 hex characters | Legacy CDMA, largely retired | No |
| EID | 32 digits | eSIM chips, not the handset itself | Yes, a mod-97 scheme |
| Manufacturer serial | Varies | Vendor-internal warranty and support records | No standard |
Getting these mixed up is the most common source of failing device-field validation. Only the IMEI and IMEISV carry a Luhn check digit.
Frequently asked questions
Are generated IMEI numbers real?+
No. They are format-valid test numbers with a correctly computed Luhn check digit, but they are not assigned to real phones or tablets. The Type Allocation Code is a reserved test value rather than a real device model, so a lookup will not return a manufacturer. Use them only as sample data.
Can I use a generated IMEI to unlock a phone or register a device?+
No. Never use generated IMEI numbers for unlocking, carrier registration, warranty claims, blacklist or stolen-device lookups, device resale, insurance claims or KYC. Those systems verify the identifier against real allocation and device records, so a test value cannot work and attempting it may itself be an offence.
Will these IMEI numbers pass validation?+
They pass length and Luhn checksum validation, which is what most form fields and client-side validators check. Systems that verify the Type Allocation Code against the GSMA database, or that look up a real device model or carrier record, will correctly reject them — which is the expected and desirable behaviour for test data.
How is the IMEI check digit calculated?+
With the Luhn mod-10 algorithm over the first 14 digits. Walking right to left, double every second digit starting with the one next to the check position, subtract nine from any result above nine, and sum everything. The check digit is (10 − sum mod 10) mod 10, the value that brings the total to a multiple of ten.
What do the 15 digits of an IMEI mean?+
Digits 1–8 are the Type Allocation Code identifying the device model, and its first two digits are the Reporting Body Identifier that issued it. Digits 9–14 are the serial number, unique within that TAC. Digit 15 is the Luhn check digit.
What is the difference between an IMEI and an IMEISV?+
An IMEISV is 16 digits: the same 14-digit TAC and serial, followed by a 2-digit software version number in place of the check digit. Because it has no check digit, an IMEISV cannot be validated by checksum alone — a common reason device-field validation fails unexpectedly.
Can I generate the same IMEI numbers again later?+
Yes. Generation is a pure function of a seed, so the free API returns byte-identical values for the same seed parameter. That makes a generated batch safe to commit as a test fixture instead of regenerating it on every run.
How many test IMEI numbers can I generate at once?+
Up to 100 on this page, with copy-all plus CSV and JSON download, and up to 1,000 per request from the free API — a higher cap than the identity endpoints because IMEI generation is pure arithmetic with no locale data to load.
Is checking my own phone's IMEI the same thing as this?+
No, and this tool is not for that. Your device's real IMEI is shown in its settings or by dialling *#06#. This page generates fictional identifiers for testing software; it cannot look up, validate against, or tell you anything about a real device.
Is the IMEI generator free?+
Yes — free and unlimited, with no sign-up and no API key. The site is funded by advertising on the page, not by charging for the data.