In some cases, the library cannot tell if the leading digits of a phone number

are intended to be the country calling code, or the start of the national

code><national significant number>, it is safe to put a "+" in front to

indicate this to the library.

When parsing, the library does its best to extract a phone number out of the

given input string. It looks for the phone number in the provided text; it

* [#1199](http://github.com/google/libphonenumber/issues/1199)

* [#1813](http://github.com/google/libphonenumber/issues/1813)

Usually, when parsing, we remove a country's national or trunk prefix, so we can

store a normalized form of the number. This is usually, but not always, a

when formatting since other short-codes do not, and we would be irreparably

changing the phone number.

`00` is not an international prefix (IDD) in every region, so it's not

equivalent to `+`.

Also see `internationalPrefix` in

[`resources/PhoneNumberMetadata.xml`](http://github.com/google/libphonenumber/blob/master/resources/PhoneNumberMetadata.xml).

To understand the behavior of functions, please refer to the documentation in

the Javadoc/C++ header files. For example, see `isPossibleNumberWithReason` in

[`PhoneNumberUtil`](https://github.com/google/libphonenumber/blob/master/java/libphonenumber/src/com/google/i18n/phonenumbers/PhoneNumberUtil.java).

Short numbers are out of scope of

[`PhoneNumberUtil`](https://github.com/google/libphonenumber/blob/master/java/libphonenumber/src/com/google/i18n/phonenumbers/PhoneNumberUtil.java).

For short numbers, use

[`ShortNumberInfo`](https://github.com/google/libphonenumber/blob/master/java/libphonenumber/src/com/google/i18n/phonenumbers/ShortNumberInfo.java).

Our phone number library can tell that a number range is valid when there is

sufficient official documentation, with some latency after this fact is brought

such a verification step given the complicated international world we live in,

with varying standardization practices in different regions.

Not necessarily.

US are not valid, because without the rest of the number it is impossible

for the library to canonicalize this.

Rarely! Many people have phone numbers that do not belong to the country they

live in. This applies particularly to mobile numbers, but may also be true

`FIXED_LINE` number for a business matches the country it is in, to try and spot

data errors.

This could be due to number simplification. In order to keep the size of the XML

files to a reasonable level, it's necessary in some regions (e.g. "DE" or "AT")

valid ranges with different formats). Note that this also applies to attributes

like "national only" or geocoding information.

SMSs can be sent to `MOBILE` or `FIXED_LINE_OR_MOBILE` numbers. However,

in some countries it is possible to configure other types, such as normal

land-lines, to receive SMSs.

Some number ranges are explicitly defined as being for fixed-line or mobile

phones. We even represent ranges defined as being "Mostly land-line" in this

way.

The ability to keep your mobile phone number when changing carriers. To see whether a region supports mobile number portability use [isMobileNumberPortableRegion](https://github.com/google/libphonenumber/blob/58247207903f917839001bc62525a5b48a475b7e/java/libphonenumber/src/com/google/i18n/phonenumbers/PhoneNumberUtil.java#L3524).

Not all regions support mobile number portability. For those that don't, we return the carrier when available. For those that do, we return the original carrier for the supplied number.

libphonenumber does not support M2M numbers in general, but only in one exception case where in Netherlands 097X M2M numbers are used as regular mobile phone numbers.

At the moment Libphonenumber can only support phone numbers that can be dialled by us, not by machines. If you found any humanly diallable M2M numbers that library is not supporting, please raise an [issue here](http://issuetracker.google.com/issues/new?component=192347) with all authoritative and specific documentation such as government sources, which have varied definitions.

Official authority has [explicitly stated](https://www.acm.nl/en/publications/information-about-dutch-097-numbers-non-dutch-providers) that this range “should be made accessible, just like other, regular number series from the Netherlands” and that “you can set up a voice and SMS connection towards prefix +31-97 in the same way as you have done already with the +31-6 series.[...] you should enable your systems for voice telephony for the numbers

in the +31-97 series”. This means, however, that there might be cases where the library would categorise a number as a valid mobile number, but in reality, the particular number is used as pure M2M, is not SMS or voice-enabled. There is not much we can do from our side about this, since we always follow official guidelines.

Therefore, clients should be aware that there is possibility of false positives in NL MOBILE category. The library will continue to not support M2M numbers in general.

There are some numbers that only work for the subcribers of certain operators

for special operator-specific services. These differ from carrierSpecific since

Please see [this issue](https://issuetracker.google.com/issues/65238929) for more

context, and file a new issue if you're able to provide more information than this.

We support parsing and storing numbers from a minimum length of two digits to a

maximum length of 17 digits currently (excluding country calling code). The ITU

standard says the national significant number should not be longer than

fifteen digits, but empirically this has been proven not to be followed by all

countries.

No, phone number formatting is country-specific and language-independent. E.g.

formatting a US number in a French way (e.g. the way a France number is

native, not ASCII, digits; our phone number library supports parsing these but

doesn't support it at formatting time at the moment.

The formatting within a country changes sparingly, but may be announced explicitly

or noted implicitly in a national numbering plan update that introduces a new number

See [issue #1996](https://github.com/google/libphonenumber/issues/1996)

for some additional discussion.

If we don't think we can guarantee that the number is diallable from the user's

mobile phone, we won't return anything. This means that for numbers that we

okay providing a number that may not be diallable, you can call another of our

formatting numbers instead.

We use the word "metadata" to refer to all information about phone numbering in

a particular country - what the country code, international and national

dialling prefixes are, what carrier codes are operational, which phone numbers

are possible or valid for a particular country, how to optimally format them,

which prefixes represent a particular geographical area, etc.

In theory, phone numbering plans are all supposed to be administered through the

ITU. Many countries' phone numbering plans may be found on the [ITU website](

carrier & geo mappings). If you can connect us with partners in the industry

to achieve this, please do so. Thanks!

Certain countries' mobile and/or fixed line ranges may overlap or too granular,

which may make accurate identification impossible. Eg: Argentina and Mexico.

dialling patterns were deprecated, we have continued to maintain mobile and

fixed-line ranges at higher level, returning type as [`FIXED_LINE_OR_MOBILE`](#fixed_line_or_mobile)

Though library has stopped supporting below older dialling codes in the canonical

form and formatting results, we are lenient in parsing the number, i.e removing

all older codes.

period, so we decided to support them for longer time. However, we will stop this as

part of [this issue](https://issuetracker.google.com/issues/205606725). More details there.

We only support a country if:

a proposed new international telecommunication public correspondence service,

shared code".)

Although some numbers beginning with "001 803" or "007 803" do work in Indonesia

to reach toll-free endpoints, these numbers are hard to support because they

made to interpret the "00x" as something other than an IDD: this could have

undesirable side-effects when parsing other numbers.

For JavaScript, Java and C++ there is the option to use a stripped-down version

of the metadata. Currently this only removes the example number metadata, so the

file](https://github.com/google/libphonenumber/blob/master/java/build.xml)

itself.

When possible, use the [latest

version](https://github.com/google/libphonenumber/releases) of

* If you depend on the carrier or geocoder jar, you also need to depend on

the prefixmapper jar.

automate updating them from upstream. To avoid net increase of app size, remove them

from libphonenumber.

The libphonenumber team's support of the C++ library on Windows is primarily to

support Chromium's build environment, and we depend on the community to support

* [#1555](https://github.com/google/libphonenumber/issues/1555) to allow

Windows to build cpp library with pthreads for multi-threading

We supply example numbers as part of the library API. While we aim to have numbers

that are either explicitly allocated by the country as a test number, or look

please report this through Google's new [Issue Tracker](http://issuetracker.google.com/issues/new?component=192347).

Only our internal team will have access to your identity (whereas GitHub usernames are public).

Eg: National number of 900184080594493**87**, ```region: JP``` is parsed as

900184080594493**90**. Reason: When the provided number is more than the max