Bulk IMEI Generator: Generate Thousands of Test IMEIs for QA & Automation

One test IMEI is enough to validate a form field. One hundred gets you through a basic integration test. But when you are running a QA automation suite for an enterprise MDM platform, seeding a database for load testing, or building a simulation environment for a telecom backend, you need thousands of structurally valid IMEI numbers — fast, varied, and correctly formatted. This is what a bulk IMEI generator is for.

This guide explains when and why bulk IMEI generation matters, the technical requirements for generating valid IMEIs at scale, and how to integrate batch-generated IMEIs into real-world QA and development workflows.

Why You Cannot Just Use Random 15-Digit Numbers

The naive approach to bulk IMEI test data is to generate random 15-digit strings. It seems simple, but it fails in every meaningful test scenario:

1. Luhn validation fails: Every real IMEI has a check digit calculated by the Luhn algorithm. Systems that validate IMEI format will reject any number that doesn't pass Luhn. Purely random 15-digit strings fail Luhn approximately 90% of the time.

2. TAC validation fails: Enterprise MDM platforms, carrier systems, and device databases identify device manufacturer and model from the first 8 digits (the TAC). A random number that doesn't start with a registered TAC will be flagged as an unrecognized device or outright rejected.

3. Uniqueness problems: For database testing, you need genuinely unique IMEIs. Naive random generation can produce duplicates, causing UNIQUE constraint violations in your schema and false test failures.

4. No realistic distribution: Real-world device fleets have a mix of manufacturers and models. A test dataset that's 100% random numbers doesn't reflect the TAC distribution you'd see in production, which can mask bugs that only manifest with certain device types.

A proper bulk IMEI generator handles all four of these requirements: valid Luhn checksums, authentic TAC prefixes, guaranteed uniqueness across the batch, and configurable distribution across device families.

Use Cases for Bulk IMEI Generation

1. Database Seeding and Schema Testing

When building or migrating a database that stores device identifiers, you need realistic test data at scale. Empty databases and single-record tests do not reveal:

• Index performance under realistic cardinality
• Query plan behavior when filtering by manufacturer TAC prefix
• Partition pruning efficiency in large-scale deployments
• Constraint validation timing under insert load

Seeding a test database with 100,000 unique, properly formatted IMEIs across a realistic mix of manufacturers gives you confidence that your schema will perform in production.

2. Load Testing and Performance Benchmarking

Performance tests require realistic data volume. If you are benchmarking a device lookup API that needs to handle 10,000 requests per minute, you cannot send the same IMEI in every request — caching will make the results artificially good, and rate-limiting systems may block repeated identical requests.

You need a large pool of unique, valid IMEIs to draw from. A bulk generator lets you pre-generate that pool — 50,000, 100,000, or more — and feed it to your load testing tools (k6, JMeter, Locust, Gatling) for realistic request variety.

3. MDM Platform Development

Enterprise Mobile Device Management platforms need to handle real-scale device inventories. A corporate deployment might manage 5,000 to 500,000 devices. When testing your MDM platform's scalability — enrollment workflows, policy assignment, inventory queries, compliance reporting — you need test device records in those quantities.

Bulk-generated IMEIs let you populate MDM staging environments with synthetic device inventories at production scale, without needing physical devices or real customer data.

4. QA Automation Pipelines

Automated test suites that validate IMEI-related functionality need unique test data for each test run. Hardcoding a small set of test IMEIs into your test fixtures creates test pollution: tests start interfering with each other because they share state around the same identifiers.

A better pattern is to generate fresh IMEIs on demand at the start of each test run, or to maintain a large pre-generated pool and draw from it with a counter or random offset. Bulk generation supports both approaches.

5. Telecom Network Simulation

Telecom engineers building or testing HLR (Home Location Register), VLR (Visitor Location Register), or EIR (Equipment Identity Register) systems need to simulate subscriber records at scale. A realistic test HLR might contain millions of subscriber records, each with an IMSI–IMEI pair. Generating millions of valid IMEIs — properly distributed across device families — is not something you do by hand.

6. Second-Hand Device Marketplace Testing

Platforms that verify IMEI status (blacklist checks, carrier lock status, warranty lookup) need to test their lookup pipeline with varied input. You want to test:

• Fast path: IMEI not in any blacklist (happy path, most common)
• Slow path: IMEI found in blacklist database
• Invalid format: malformed input
• Edge cases: valid Luhn but non-existent TAC

A bulk generator gives you the test pool for the first scenario — a large set of known-clean IMEIs to use as your baseline happy-path test data.

Technical Requirements for Valid Bulk IMEI Generation

Generating valid IMEIs at scale requires getting several things right simultaneously:

Luhn Algorithm at Scale

Every generated IMEI needs a valid Luhn check digit. Here is the algorithm implemented in Python, suitable for bulk generation:

import random

def luhn_checksum(digits_14: str) -> int:
    """Calculate the Luhn check digit for a 14-digit string."""
    digits = [int(d) for d in digits_14]
    # Double every second digit from the right
    for i in range(12, -1, -2):
        digits[i] *= 2
        if digits[i] > 9:
            digits[i] -= 9
    total = sum(digits)
    return (10 - (total % 10)) % 10

def generate_imei(tac: str) -> str:
    """Generate a valid IMEI with the given 8-digit TAC."""
    serial = str(random.randint(0, 999999)).zfill(6)
    base = tac + serial
    check = luhn_checksum(base)
    return base + str(check)

def generate_bulk(tac: str, count: int) -> list[str]:
    """Generate a list of unique valid IMEIs for a given TAC."""
    seen = set()
    results = []
    while len(results) < count:
        imei = generate_imei(tac)
        if imei not in seen:
            seen.add(imei)
            results.append(imei)
    return results

# Example: Generate 1000 Galaxy S24 Ultra IMEIs
imeis = generate_bulk("35349010", 1000)
print(f"Generated {len(imeis)} unique IMEIs")
print(f"Sample: {imeis[:5]}")

TAC Distribution for Realistic Datasets

For most testing purposes, you want your bulk dataset to reflect a realistic manufacturer distribution. Here is a typical enterprise mobile fleet composition:

Building your bulk test dataset with this kind of distribution means your performance benchmarks, query plans, and policy logic are tested against representative data — not an artificially uniform dataset.

Ensuring Uniqueness

For database seeding, uniqueness is non-negotiable. Two approaches:

1. Set-based deduplication (shown in the Python example above): Track generated IMEIs in a set and regenerate on collision.
2. Sequential serial numbers: Increment the serial number field (digits 9–14) sequentially rather than randomly. This guarantees uniqueness within a TAC block without collision checking. With 6 serial digits, each TAC supports up to 1,000,000 unique IMEIs.

Bulk Generation at Scale: Numbers to Know

How many unique IMEIs can a single TAC support? The serial number is 6 digits (000000–999999), giving a maximum of 1,000,000 unique IMEIs per TAC. For very large datasets (millions of records), you need to use multiple TAC codes.

Integrating Bulk IMEIs with QA Tools

With k6 (JavaScript load testing)

import { SharedArray } from 'k6/data';

// Pre-load 50,000 generated IMEIs from a file
const imeis = new SharedArray('imeis', function () {
  return open('./test_imeis.txt').split('\n').filter(l => l.length === 15);
});

export default function () {
  // Pick a random IMEI from the pool
  const imei = imeis[Math.floor(Math.random() * imeis.length)];

  const res = http.post('https://api.example.com/devices/lookup', {
    imei: imei,
  });

  check(res, {
    'status is 200': (r) => r.status === 200,
    'returns device info': (r) => r.json('manufacturer') !== undefined,
  });
}

With pytest (Python test suite)

import pytest
import random

# Fixture that provides unique IMEIs per test
@pytest.fixture
def unique_imei(imei_pool):
    """Provide a unique IMEI from a pre-generated pool."""
    return imei_pool.pop()

@pytest.fixture(scope="session")
def imei_pool():
    """Load pre-generated IMEI pool at session start."""
    with open("test_data/bulk_imeis.txt") as f:
        imeis = [line.strip() for line in f if len(line.strip()) == 15]
    random.shuffle(imeis)
    return imeis

def test_device_lookup(unique_imei, api_client):
    response = api_client.lookup_device(unique_imei)
    assert response.status_code == 200
    assert response.json()["format_valid"] is True

With SQL (Database seeding)

-- PostgreSQL: bulk insert from CSV
CREATE TEMP TABLE temp_imeis (imei CHAR(15));

COPY temp_imeis FROM '/path/to/bulk_imeis.csv' CSV;

-- Insert into devices table with additional metadata
INSERT INTO test_devices (imei, created_at, status)
SELECT
    imei,
    NOW() - (random() * INTERVAL '365 days'),  -- Random creation date
    CASE WHEN random() < 0.95 THEN 'active' ELSE 'inactive' END
FROM temp_imeis
ON CONFLICT (imei) DO NOTHING;

SELECT COUNT(*) FROM test_devices;  -- Verify count

Using RandomIMEI.com for Bulk Generation

RandomIMEI.com supports bulk generation directly from the web interface and API. You can:

• Generate up to thousands of IMEIs in a single request
• Filter by manufacturer (Apple, Samsung, Google, etc.)
• Export as plain text (one per line), CSV, or JSON
• Use the API endpoint for programmatic integration into CI/CD pipelines

Each generated IMEI:

• Has a valid Luhn check digit
• Uses a real manufacturer TAC prefix
• Is guaranteed unique within the batch
• Is not assigned to any real device and not in any carrier database

This is the fundamental property that makes bulk-generated IMEIs safe for testing: they are valid data structures that will pass any format check, but they do not correspond to real hardware and cannot be used to access real carrier services.

Output Format Options for Bulk IMEIs

Depending on your workflow, you may need different output formats:

What Bulk-Generated IMEIs Are NOT For

This is important to state clearly. Bulk IMEI generation is a legitimate software development practice. It is not a tool for:

• IMEI spoofing: Reprogramming a real device to use a fake IMEI is illegal in virtually every country. Generated test IMEIs exist only as data; they have no mechanism to be "flashed" onto hardware.
• Bypass lists: Carrier blacklists and device registries check IMEIs against real databases. Generated IMEIs are unknown to these databases and cannot bypass or circumvent any real-world security system.
• Fraud: Insurance fraud, device finance fraud, or any other scheme that involves misrepresenting device identity. Generated test data exists for development environments, not for submission to real-world systems.

The legal framework is consistent across jurisdictions: using false IMEIs to gain access to telecommunications services, commit fraud, or bypass security is a criminal offense. Generating test data for software development is not.

Frequently Asked Questions

How many unique IMEIs can I generate from a single TAC code?

Each TAC has a 6-digit serial number field (digits 9–14), which allows for 1,000,000 unique IMEIs per TAC. For datasets larger than 1 million, you need to distribute generation across multiple TAC codes. For most testing scenarios — even large enterprise MDM deployments — a single TAC is more than sufficient.

What is the fastest way to generate 1 million test IMEIs?

The most efficient approach is sequential serial generation rather than random: start at serial 000001 and increment to 999999 for a given TAC, applying the Luhn check digit calculation at each step. This avoids collision checking entirely and can generate 1 million valid IMEIs in seconds on any modern hardware.

Can I use bulk-generated IMEIs in a CI/CD pipeline?

Yes. The recommended pattern is to generate a large pool of IMEIs (e.g., 100,000) once and commit them to your test data repository. Each test run draws from this pool. Alternatively, generate IMEIs on demand in a pre-test setup script using an API call or a local generation function. Both approaches work; the pre-generated pool is simpler and faster at runtime.

Do bulk-generated IMEIs work with real IMEI checker tools?

Generated IMEIs will pass format validation on any IMEI checker (they are valid 15-digit Luhn numbers with real TAC prefixes). They will show "clean/not blacklisted" status because they are not in any real device database. They will not return device model information, purchase history, or warranty status because they are not registered. This is expected and correct behavior for test data.

How do I ensure no duplicates in a bulk-generated dataset?

Use one of two methods: (1) Set-based deduplication — track generated IMEIs in a hash set during generation and reject collisions. (2) Sequential serial numbers — increment the serial field deterministically, which guarantees uniqueness by construction. For datasets under 100,000, either method works fine. For millions of records, sequential generation is significantly more efficient.

Is there a risk that a generated IMEI matches a real device's IMEI?

Statistically, yes — the IMEI space has approximately 10^15 possible values, and there are roughly 15 billion active devices, so the collision probability for any single generated IMEI is about 1.5 × 10^-5 (0.0015%). In practice, this is negligible for testing purposes. Generated IMEIs are explicitly not submitted to real carrier or GSMA systems, so even a theoretical collision has no real-world consequence.