Test phone numbers by country: fictional ranges for developers

Safe test phone numbers are the ranges a national regulator has reserved for fiction and promises never to give to a subscriber. As of November 2026 these include 07700 900000 to 07700 900999 in the UK (Ofcom), 555-0100 to 555-0199 in every North American area code (NANPA), the ACMA's list in Australia, Germany's "drama numbers" and six fiction blocks in France's numbering plan. A random number that merely looks valid can belong to a real person. If your test suite or staging environment sends to it, a stranger gets your one-time codes.

This guide lists each range with its regulator source, shows what libphonenumber really says about them (some fail validation), and explains how to test an OTP flow without texting anyone. We ran every code sample on 2026-11-07 with Python 3.12 and phonenumbers 9.0.40, Node.js 24 with libphonenumber-js 1.13.13, and our public sandbox. We only list a country where we could trace the range to the regulator itself.

Which phone numbers are reserved for testing in each country?

Sources for each row:

• United Kingdom. Ofcom keeps drama numbers in the mobile range, in the main city area codes and in the non-geographic ranges. It says they won't be allocated to providers in the foreseeable future (Ofcom, drama numbers). For an area code it doesn't list, Ofcom points to 01632 960xxx.
• North America. NANPA writes that "the fictitious, non-working numbers, 555-0100 through 555-0199, will remain reserved for entertainment/advertising" (NANPA). The rest of the 555 line numbers were released in 2016, so 555-1234 can be a working number today.
• Australia. The ACMA reserves numbers "for creative works, such as in TV shows and films" that "do not belong to people or businesses". Its list, last updated on 3 September 2026, has 30 mobile numbers, eight landline blocks, six freephone and five local-rate numbers (ACMA). Our Australia guide has the full mobile list.
• Germany. The Federal Network Agency's page "Rufnummern für Medienproduktionen" lists the numbers above as never to be assigned, and says no further drama numbers will be added. Our Germany guide shows them in tested code.
• France. The numbering plan in force since 1 January 2026 reserves the six roots above for fiction (Arcep, plan national de numérotation). Each is a block of 10,000 numbers. More detail is in our France guide.

Which countries have no fictional range?

Many. As of November 2026 we found none for these, so say so in your test plan rather than inventing one:

• Japan. We found no range for fiction or testing published by the Ministry of Internal Affairs and Communications.
• The Netherlands. The Dutch numbering plan reserves no block for films, books or examples (see our Netherlands guide).
• Poland. The national numbering plan of December 2024 has no fiction range either.
• Ireland. ComReg's numbering consultations discuss numbers for drama, but we couldn't open the operative text from the regulator, so we don't list a range here. Check with ComReg before you rely on one.

For these countries, use libphonenumber's example numbers in offline parser tests only (see below), mask everything else with X, and test lookups with a sandbox.

Why not just make up a valid-looking number?

Because "valid" means the number is in a range that operators can assign, not that nobody has it. The libphonenumber FAQ puts it plainly: a valid range is "one from which numbers can be freely assigned by carriers to users", and "do not rely on libphonenumber to determine whether numbers are currently assigned to a specific user and reachable" (libphonenumber FAQ). A made-up +44 7911 123456 or +1 212 555 1234 passes validation and may well ring a real phone.

What goes wrong in practice:

• A stranger gets your test traffic. A staging job with a hard-coded number sends real OTPs, order updates or marketing to someone who never signed up. That is unsolicited messaging, and a full phone number is personal data.
• Your SMS bill grows. Test loops send real, billed messages. If the number is premium-rate or in an expensive destination, each send costs more.
• Your sender reputation suffers. Recipients who report your test messages as spam count against your sender ID or short code.
• Example numbers aren't safe either. The same FAQ says libphonenumber tries to use test or fictitious-looking numbers as examples, but "we sometimes have numbers that do connect to a real person". Use them to test parsing, never to send.

How does libphonenumber treat fictional ranges?

Inconsistently, because the library follows each country's assignable ranges, and the regulators placed their fiction blocks differently. Some sit inside normal ranges and validate; others sit in blocks the metadata excludes. Here is the script we ran:

import phonenumbers
from phonenumbers import PhoneNumberType as T

names = {v: k for k, v in vars(T).items() if k.isupper()}
cases = [
    ("GB", "07700 900001"), ("GB", "01632 960001"), ("GB", "020 7946 0000"),
    ("GB", "0808 157 0001"), ("GB", "0306 999 0001"), ("GB", "0909 879 0001"),
    ("US", "(212) 555-0123"), ("CA", "(416) 555-0199"),
    ("AU", "0491 570 006"), ("AU", "(02) 5550 1234"), ("AU", "1800 975 707"),
    ("DE", "0152 28817386"), ("DE", "030 23125012"),
    ("FR", "01 99 00 12 34"), ("FR", "06 39 98 12 34"),
]
for region, raw in cases:
    n = phonenumbers.parse(raw, region)
    e164 = phonenumbers.format_number(n, phonenumbers.PhoneNumberFormat.E164)
    ok = phonenumbers.is_valid_number(n)
    t = names[phonenumbers.number_type(n)] if ok else "-"
    print(f"{region}  {raw:<16} {e164:<15} possible={phonenumbers.is_possible_number(n)!s:<5} valid={ok!s:<5} {t}")

Output (2026-11-07, phonenumbers 9.0.40):

GB  07700 900001     +447700900001   possible=True  valid=False -
GB  01632 960001     +441632960001   possible=True  valid=False -
GB  020 7946 0000    +442079460000   possible=True  valid=True  FIXED_LINE
GB  0808 157 0001    +448081570001   possible=True  valid=True  TOLL_FREE
GB  0306 999 0001    +443069990001   possible=True  valid=True  UAN
GB  0909 879 0001    +449098790001   possible=True  valid=True  PREMIUM_RATE
US  (212) 555-0123   +12125550123    possible=True  valid=True  FIXED_LINE_OR_MOBILE
CA  (416) 555-0199   +14165550199    possible=True  valid=True  FIXED_LINE_OR_MOBILE
AU  0491 570 006     +61491570006    possible=True  valid=True  MOBILE
AU  (02) 5550 1234   +61255501234    possible=True  valid=True  FIXED_LINE
AU  1800 975 707     +611800975707   possible=True  valid=True  TOLL_FREE
DE  0152 28817386    +4915228817386  possible=True  valid=True  MOBILE
DE  030 23125012     +493023125012   possible=True  valid=True  FIXED_LINE
FR  01 99 00 12 34   +33199001234    possible=True  valid=True  FIXED_LINE
FR  06 39 98 12 34   +33639981234    possible=True  valid=False -

libphonenumber-js 1.13.13 (the /max metadata) gave the same verdicts for the eight numbers we cross-checked: invalid for 07700 900001, 01632 960001 and 06 39 98 12 34, valid with the same type for the rest.

What this means for your tests:

• Every row is "possible": the length is right. Only full validation tells them apart.
• The UK drama mobiles fail validation. If your sign-up form validates with libphonenumber, it will reject +447700900001 before your code ever reaches the OTP step. Either allow the drama block explicitly in test builds, or use a fiction number that validates, such as an Australian 0491 570 xxx mobile or a German drama mobile.
• The US 555-01XX numbers pass as FIXED_LINE_OR_MOBILE. That makes them good fixtures for the happy path, and a risk in production: if they shouldn't reach your systems, filter ^\+1\d{3}55501\d{2}$ yourself. Our US guide has a helper for it.
• Valid doesn't mean safe to send. The ranges here are safe because the regulator says so, not because the library approves them. Our post on whether libphonenumber checks if a number is active explains the difference. To try a single number by hand, the free phone number validator gives the same kind of answer in the browser.

What test values does the MobileValidate sandbox use?

The UK drama mobiles, +447700900000 to +447700900999. Each documented number always returns the same answer, so you can test every branch: registered, unreachable, unknown, pending, unsupported and the request errors. The public sandbox key mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym needs no sign-up and is never billed. The full list is on test values and test mode.

Our API treats these numbers as valid even though libphonenumber doesn't, so they get through to the check. Here is a real request for the carrier and live network status (HLR) checks:

curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym" \
  -H "Content-Type: application/json" \
  -d '{"numbers":["+447700900001","+447700900002","+447700900003","+447700900005"],"checks":["carrier","hlr"],"wait":5}'

The answers we got on 2026-11-07, shortened to the fields that matter:

Every row also carried "test": true and the lookup "livemode": false. The sandbox refuses anything that isn't a documented test value, even another country's fiction number. Sending the ACMA mobile +61491570006 returned:

{"error":{"code":"sandbox_magic_only","message":"The public sandbox key only accepts the documented test numbers and e-mail addresses.","status":403,"retryable":false,"param":"numbers[0]"}}

That is deliberate: the public key can't be used to look up real people. A personal test key from get a test key accepts any number and returns a stable, made-up answer marked "test": true, without touching a network. In the other direction, a live key sent a test number answers 400 test_number_only, so test data can't leak into real lookups or your bill.

How do I test an OTP flow without texting real people?

Keep three layers apart: what you send, what you check before sending, and which numbers your fixtures use.

1. Never let test environments reach a real SMS route. Swap the sender for a fake that records the code (a log line, a database table, or your provider's own test mode). Fail the build if a staging config holds a live SMS credential.
2. Use only reserved fictional numbers in fixtures, seed data and screenshots. Pick from the table above. If you need a number that passes libphonenumber, use an Australian or German fiction mobile or a US 555-01XX number. If your test needs to reach the pre-send check, use the sandbox's UK drama numbers.
3. Test the pre-send decision against fixed answers. A check before the code goes out stops SMS to dead or wrong numbers. Our post on OTP fraud prevention checks covers which checks to run. Your code should handle every outcome, including unknown and rate limits.

Here is a small gate we ran against the sandbox. It sends the code unless the network says the number is unreachable, and it fails open on errors, so a lookup problem never locks a real user out:

// Decide whether to send an OTP by SMS, using the live network status (HLR) check.
const KEY = process.env.MV_KEY; // test key in CI, live key in production

async function smsAllowed(e164) {
  const res = await fetch("https://api.mobilevalidate.com/v1/lookup", {
    method: "POST",
    headers: { Authorization: `Bearer ${KEY}`, "Content-Type": "application/json" },
    body: JSON.stringify({ numbers: [e164], checks: ["hlr"], wait: 5 }),
  });
  if (res.status === 429) return { send: true, why: "rate limited: fail open, send" };
  if (!res.ok) return { send: true, why: `HTTP ${res.status}: fail open, send` };
  const hlr = (await res.json()).results[0].checks["number.hlr"];
  if (hlr.status !== "completed") return { send: true, why: `${hlr.status} (${hlr.reason ?? "-"}): send, watch the result` };
  if (hlr.attributes.status === "unreachable") return { send: false, why: "unreachable: offer another channel" };
  return { send: true, why: `${hlr.attributes.status} on ${hlr.attributes.network}` };
}

for (const n of ["+447700900001", "+447700900002", "+447700900003", "+447700900005", "+447700900429"]) {
  console.log(n, JSON.stringify(await smsAllowed(n)));
}

Output with MV_KEY=mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym on 2026-11-07:

+447700900001 {"send":true,"why":"reachable on Test Mobile"}
+447700900002 {"send":false,"why":"unreachable: offer another channel"}
+447700900003 {"send":true,"why":"unknown (UPSTREAM_TIMEOUT): send, watch the result"}
+447700900005 {"send":true,"why":"unsupported_country (UNSUPPORTED_COUNTRY): send, watch the result"}
+447700900429 {"send":true,"why":"rate limited: fail open, send"}

Five fixtures cover the branches that break in production: the happy path, a dead number, a timeout, an unsupported country and a 429. Whether to fail open or closed is your policy. For a sign-up form, failing open is usually right. For a flow that is being abused by SMS pumping, you may prefer to block and offer another channel. Both branches are now testable without a single real SMS.

Which MobileValidate checks help once you go live?

The same request with a live key checks real numbers that your users give you:

• Live network status (HLR): reachable, unreachable or unknown, plus porting and the current network. US$0.006 per real-time check and US$0.005 in bulk jobs.
• Carrier lookup: line type and carrier, to avoid sending SMS to landlines. US$0.003 real time, US$0.0015 in bulk. There is also a free public carrier lookup on that page (3 a day, no sign-up).

Prices are from our live catalog on 2026-11-07, per number and check. Unknown, unsupported and invalid results are never billed. Every live account can run 20 phone numbers and 10 e-mail addresses through the real checks for free on the dashboard's Try it page, and you can get a free job estimate before any bulk run. Top-ups of US$100 or more get a 5% bonus, US$500 or more 8%, and US$2,000 or more 10%. Live access is approved automatically: request access.

Use the checks only on numbers that people gave you, such as at sign-up, checkout or a contact-detail change. Don't use them to test number ranges or build lists. Our API refuses requests that look like sequential ranges.

What are the key takeaways?

• Use regulator-reserved fiction ranges in fixtures, seed data, docs and screenshots: UK 07700 900xxx, NANP 555-0100 to 555-0199, the ACMA list, Germany's drama numbers and Arcep's six fiction blocks.
• Many countries have none, including Japan, the Netherlands and Poland. Say so, and keep tests offline or in a sandbox.
• "Valid" isn't "unassigned". A made-up number that passes libphonenumber can belong to a real person, and so can libphonenumber's example numbers.
• libphonenumber rejects some fiction ranges, including the UK drama mobiles and the French 06 39 98 block. Allow them explicitly in test builds, or choose a range that validates.
• Test the OTP decision, not the SMS. Fake the sender, and run the pre-send check against a sandbox with fixed answers for every branch.
• More free utilities for this kind of work are on our free tools page.