Pakistan phone numbers: format, mobile prefixes, validation and messaging rules

Pakistani numbers use the country code +92. Mobile numbers have 10 digits after the code and start with 3 (03XX when dialled at home); in E.164 they look like +92 3XX XXXXXXX. Because subscribers can port their number to another operator, the 03XX code doesn't tell you the current network, and marketing texts must go through PTA-approved short codes to people who haven't opted out through the 3627 register.

This guide is part of our phone numbers by country series. The tables are generated from libphonenumber's metadata, our MNP atlas and our public catalog. Example numbers are masked with X. The Pakistan Telecommunication Authority (PTA) site didn't respond to automated requests from our server, so on 2026-09-27 we read its gazette notifications and guidelines through Internet Archive copies captured between May 2025 and May 2026; the scanned gazettes were read page by page. This is a summary, not legal advice.

#What does a Pakistani phone number look like?

A mobile number is 03XX XXXXXXX at home: the trunk prefix 0, a three-digit code starting with 3, and seven digits. From abroad it is +92 3XX XXXXXXX. Landlines start with an area code and have 9 or 10 digits after +92.

Store only the E.164 form. Pakistani forms often collect numbers as 03XX-XXXXXXX or 923XX… without a plus; a numbering-plan library with the default region PK turns all of them into +923….

#Which prefixes are mobile numbers?

All mobile numbers start 03, but not every 03XX code is in use. For each 2-digit block, the generator counted every 10-digit number that libphonenumber's mobile pattern for PK accepts:

In short: 030 to 032, 034 and 037 are fully in use, 033 except 0338, and only 0355 and 0364 in the 035 and 036 blocks. A number such as 0350 XXXXXXX has the right shape but isn't a mobile number today.

#03XX network codes and porting

Pakistanis often call the 03XX code the "network code", because each code was allocated to one operator. PTA's porting guidelines keep that allocation: the operator that was allocated a range stays its number range holder, and porting requests pass through a central number portability clearinghouse (PTA MNP guidelines, 2020). So the code still tells you who holds the range, and nothing more. We don't list operators by code here, because a table like that looks authoritative and is wrong for every ported number.

#How do I validate a Pakistani number in code?

Use a libphonenumber port with full metadata and the default region PK.

Python (pip install phonenumbers):

import phonenumbers


def normalize_pk(raw: str) -> str | None:
    """E.164 for a Pakistani mobile (03XX …), or None."""
    try:
        n = phonenumbers.parse(raw, "PK")
    except phonenumbers.NumberParseException:
        return None
    if (not phonenumbers.is_valid_number(n) or phonenumbers.region_code_for_number(n) != "PK"
            or phonenumbers.number_type(n) != phonenumbers.PhoneNumberType.MOBILE):
        return None
    return phonenumbers.format_number(n, phonenumbers.PhoneNumberFormat.E164)

JavaScript (npm install libphonenumber-js):

import { parsePhoneNumberFromString } from "libphonenumber-js/max";

/** "03XX XXXXXXX", "+92 3XX …", "923XX…" → E.164 for a Pakistani mobile, or null. */
export function normalizePk(raw) {
  const phone = parsePhoneNumberFromString(String(raw), "PK");
  return phone?.isValid() && phone.country === "PK" && phone.getType() === "MOBILE" ? phone.number : null;
}

We ran both on 2026-09-27 (Python phonenumbers 9.0.40, libphonenumber-js 1.13.13 with metadata 9.0.39). Both returned an E.164 number for rows 1 to 5 below and nothing for the rest. The shape regex column tests ^(?:\+92|0092|0)?3\d{9}$, the pattern most tutorials give, after spaces, dashes and brackets are removed:

Row 8 is the one to remember. 038 is shaped like a mobile number and passes the regex, but nothing is allocated there, so an OTP sent to it is wasted. More languages are in our Python and JavaScript guides.

#Does number portability change the carrier?

Yes. Pakistan's porting framework rests on PTA's Mobile Number Portability Regulations 2005 and its porting process guidelines. Our atlas records a normal porting time of four days. Under the 2020 guidelines, an inactive ported number stays in quarantine for 180 days and, if it is still unused, goes back to the range holder within 30 days. The guidelines also refer to PTA's procedure of 20 November 2013 for selling and activating SIMs through biometric verification (PTA MNP guidelines). The Pakistan row of our MNP atlas:

For routing, pricing or fraud rules, look up the current network per number instead of reading the code. Our MNP atlas compares Pakistan with 67 other countries.

#Which messaging apps and channels reach people?

SMS reaches every active mobile. For WhatsApp, Meta prices Pakistan as its own market, and its pricing page lists rate changes specific to Pakistan: lower authentication rates from 1 February 2025, lower authentication-international rates from 1 April 2025, and higher utility and authentication rates, with no change to the authentication-international rate, from 1 April 2026 (Meta pricing, read on 2026-09-27). Per Meta's rules, the authentication-international rate applies when an eligible business based in another country sends authentication messages to users with that country's calling code; eligibility depends on volume. For OTPs sent from abroad at scale, it can matter more than the local rate. Our WhatsApp OTP vs SMS OTP post shows how to compare cost per verified user.

We didn't find a published source that measures app use in Pakistan in a way we can verify, so we don't quote shares. Check which apps your own opted-in customers are registered on, route from that, and keep SMS as the fallback. Our channel-by-country guide shows the method.

#What are the rules for SMS, sender IDs and OTP?

These summarise PTA's gazette notifications as we read them on 2026-09-27. Not legal advice; ask counsel how they apply to you.

#PTA's anti-spam regulations (2009, amended 2022)

The Protection from Spam, Unsolicited, Fraudulent and Obnoxious Communication Regulations, 2009 (S.R.O. 713(I)/2009) apply to all licensed operators. They required operators to run anti-spam filtering, keep lists of subscribers disconnected for fraudulent messages, and set up a do-not-call register (PTA, 2009).

The 2nd Amendment Regulations, 2022 (S.R.O. 2402(I)/2022, gazetted 31 December 2022) rewrote the rules for marketing (PTA, 2022):

• Central register. Operators run a central Do Not Call / SMS Register (C-DNCR). Subscribers join or leave it through the short code 3627, and it covers promotional and telemarketing SMS (A2P) as well as calls.
• Authorised telemarketers. A telemarketer is a person or company authorised by PTA to send marketing messages or calls, directly or through a third party. Operators must ensure telemarketers are registered.
• Consent first. Telemarketers, through their SMS aggregator (the short-code holder), must ask each subscriber for consent by message in English and Urdu before sending marketing, and keep the record of that consent.
• Approved senders only. All marketing messages go out through approved short codes, or alphanumeric IDs set against short codes, under an agreement with the aggregator or operator.
• Unsubscribe and timing. Anyone who opted in must be able to unsubscribe, and operators must ensure such messages arrive within normal business hours.
• Robocalls are allowed only for public-awareness messages required by PTA or the Government of Pakistan.

The amendment also defines "spamming" by reference to section 25 of the Prevention of Electronic Crimes Act, 2016. And PTA's numbering FAQ says an SMS short code for content-based services requires a CVAS registration certificate first (PTA numbering FAQ).

#What that means for OTP

A one-time passcode the user asked for isn't marketing, but it travels on the same routes. Send it from a sender your provider has registered for transactional traffic, keep it free of offers, and don't reuse numbers collected for verification for marketing unless the person opted in.

#What changed recently?

The rows for PK and +92 in our numbering-plan changes dataset, built from libphonenumber's release notes:

Latest numbering-plan updates for PK: 2023-11-21 (v8.13.26), 2023-07-19 (v8.13.17), 2022-01-27 (v8.12.42), 2020-10-29 (v8.12.12), 2020-03-02 (v8.11.5).

The last metadata update for PK was in November 2023, so a library updated since then knows today's 03XX ranges. The rules that changed most recently are the 2022 anti-spam amendment above and the WhatsApp rate changes listed on Meta's pricing page.

#What can MobileValidate check for Pakistani numbers?

Generated from our public catalog:

* bulk jobs only. Catalog as fetched on 2026-09-27; the live list is at GET /v1/services.

A lookup returns network and registration facts. It never returns a subscriber's name, CNIC or address, and we don't offer "number details" searches.

Here is a practical flow for routing and fraud rules: normalise with normalize_pk(), then one lookup gives the current network, a porting hint and WhatsApp registration. It uses the public sandbox key mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym and our test values, which are UK drama numbers because the sandbox accepts only those. With a live key, pass the output of normalize_pk(). We ran it on 2026-09-27 with Python 3.12 and requests 2.31.

import os

import requests  # pip install requests

API = "https://api.mobilevalidate.com/v1/lookup"
KEY = os.environ["MOBILEVALIDATE_API_KEY"]


def current_network(numbers: list[str]) -> dict[str, dict]:
    """Current network per number. The 03XX code only shows where the range was first allocated."""
    r = requests.post(API, headers={"Authorization": f"Bearer {KEY}"}, timeout=15,
                      json={"numbers": numbers, "checks": ["carrier", "whatsapp"], "wait": 5})
    r.raise_for_status()
    out = {}
    for row in r.json()["results"]:
        carrier, wa = row["checks"]["network.carrier"], row["checks"]["whatsapp.registered"]
        attrs = carrier["attributes"] or {}
        out[row["e164"]] = {
            "status": carrier["status"],  # completed, unknown or unsupported_country
            "network": attrs.get("carrier"),
            "ported": ("original_carrier" in attrs) if attrs else None,  # None = we don't know
            "whatsapp": wa["registered"] if wa["status"] == "completed" else None,
            "billed": carrier["billed"] or wa["billed"],
        }
    return out


for number, info in current_network(["+447700900001", "+447700900002", "+447700900005"]).items():
    print(number, info)

original_carrier is only present when the range holder and the current network differ, which is why its presence is a porting hint. Test mode never bills; in live mode, unknown and unsupported answers aren't billed either. The same call with curl:

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

See carrier lookup and WhatsApp number check for the fields, and pricing for prices.

#What are the key takeaways?

• Pakistani mobiles are +92 3 plus nine digits, 03XX XXXXXXX at home; store the E.164 form.
• Not every 03XX code is live: 0338, most of 035 and 036, and 038 aren't mobile ranges today.
• The 03XX code shows the range holder, not the current network. Look it up when the operator matters.
• Marketing SMS must go through PTA-approved short codes, with consent in English and Urdu and an unsubscribe option; subscribers opt out through 3627.
• No lawful lookup returns who owns a number.

Platform, regulator and company names are used descriptively. MobileValidate is not affiliated with any of them.