HOWTO · Django

How to Store Phone Numbers in Django

Choose a Django phone-number field or a scoped validator, and learn what each approach stores.

On this page

For international numbers in a Django model, use django-phonenumber-field and its PhoneNumberField; it parses and validates numbers with region-aware phone-number metadata. A custom Django validator can be enough when your application accepts a narrow, explicitly defined number format. In either case, store phone numbers as text, not integers: a phone number is an identifier, and integer conversion can discard a leading plus sign or leading zero.

Run this example:

phone_number = "+1 415 555 0132"
print(phone_number)
print(type(phone_number).__name__)
+1 415 555 0132
str

The example shows why a phone number belongs in a string field. It does not parse or validate the number; use the package below when you need those operations for international input.

Store Phone Numbers Using a Third-Party Django App’s PhoneNumberField

Install django-phonenumber-field with either the phonenumbers extra for the fuller Python port or the phonenumberslite extra for the lighter metadata package. For example, run python -m pip install "django-phonenumber-field[phonenumbers]" in your project environment. To use the lite extra, replace phonenumbers with phonenumberslite. These are alternative extras; choose based on the metadata coverage your application needs. The project is maintained at django-phonenumber-field on GitHub. It uses python-phonenumbers, a Python port of Google’s libphonenumber.

Add "phonenumber_field" to INSTALLED_APPS in your Django settings. Then import PhoneNumberField from phonenumber_field.modelfields and declare it on a model, for example: phone_number = PhoneNumberField(unique=True). An optional number can use phone_number = PhoneNumberField(blank=True, null=True). Include the usual from django.db import models import and place these declarations inside your model class. These are framework-dependent snippets; they require Django and the package in a configured project, so they are not standalone runtime examples.

A PhoneNumberField uses string storage and gives you a phone-number object for parsing, validation, and formatting. Those are related but distinct tasks: parsing interprets input with a region context, validation checks it against numbering-plan metadata, normalization produces a canonical representation, and display formatting presents it for people. Choose a default region in your Django configuration when users may enter national-format numbers; without enough region context, such input cannot be interpreted reliably. For an existing record, access its value through the model instance, such as person.phone_number, and use its as_e164 property when you need an E.164 representation. See the project’s documentation for configuration and field details, and E.164 for the international numbering plan.

Store Phone Numbers Using a Validator and a Django Model

If the application accepts only a limited number format and you can define its rules, Django’s RegexValidator can validate a CharField. For example, import RegexValidator from django.core.validators, define phone_number_validator = RegexValidator(regex=r"^\+?1?\d{8,15}$"), and pass it to a model field as phone_number = models.CharField(max_length=16, validators=[phone_number_validator], unique=True). Put those declarations inside a model class that imports models from django.db. This is a Django-dependent illustration and has not been run as a standalone example.

That expression is a narrow pattern with an optional US country code and a digit-count range. It is not global phone-number validation, does not check whether a number is assigned, and is not equivalent to PhoneNumberField. Keep it only if those restrictions match the numbers your application accepts; otherwise use the package-based approach or define a validator against the application’s actual requirements.

E.164 permits at most 15 digits; the leading + used in its international representation is a separate character. A max_length=16 field can hold that representation, but the length setting alone does not enforce E.164 syntax or country-specific numbering rules. A validator must check the allowed prefix and digit count, and more complete international validation requires numbering-plan metadata. For either model field, decide whether numbers must be unique and whether the field may be blank or null based on your data model.