Validating Indian phone numbers, emails and PIN codes in forms

Ask ten customers for a mobile number and you will get ten formats: 9876543210, +91 98765 43210, 091-9876543210, 98765-43210, and at least one with a stray space at the end. A form that only accepts the first of those will silently lose the rest. Validating Indian phone numbers, email addresses and PIN codes well means being generous about what you accept and strict about what you store. This article gives concrete rules for each field type, with the edge cases that break real forms.

The guiding principle throughout: clean the input first, then check it. Rejecting a customer because they typed a space is a self-inflicted wound.

Phone numbers: what a valid Indian mobile looks like

Indian mobile numbers are ten digits and, at present, begin with 6, 7, 8 or 9. The country code is 91, usually written as +91. Landline numbers are different: an STD code of two to four digits plus a subscriber number, with the total generally being ten digits after the leading zero, for example 011 followed by eight digits for Delhi.

Normalise before you validate

Take whatever arrived and strip it down before applying any rule:

1. Remove spaces, hyphens, brackets and dots.
2. Strip a leading +91, 0091 or 91 if what remains is ten digits.
3. Strip a single leading 0 if what remains is ten digits.
4. Now check that you have exactly ten digits and that the first digit is 6, 7, 8 or 9 when you require a mobile.

This handles nearly every way a person might type their own number. Note the order matters: stripping all zeros or all nines blindly will mangle valid numbers.

Decide what to store

Store the normalised form in a single consistent shape, and store it as text, never as an integer, because leading zeros and plus signs matter and a ten-digit number overflows some integer columns. Two common choices are a bare ten-digit string with a separate country column, or full E.164 format such as +919876543210. E.164 is the better default if you send SMS or WhatsApp messages, because most messaging APIs expect it.

Things that go wrong

• A strict pattern on the input field that rejects spaces as the user types. Let them type, clean it afterwards.
• Blocking landlines on a form where businesses are the customers.
• Assuming ten digits worldwide. If you sell outside India, allow 7 to 15 digits and collect the country code separately.
• Using type="number" for a phone field, which allows exponent characters and strips leading zeros. Use type="tel" with inputmode set to numeric so mobile keyboards show digits.
• Not trimming the pasted value. Copy-paste from WhatsApp often brings invisible characters along.

If you need certainty that a number is reachable, validation cannot give it to you. Only sending an OTP or a message can.

Email addresses: accept more than you think

Email validation is where over-engineering does the most damage. The full specification allows far stranger addresses than most regular expressions expect, including plus signs, dots in unusual places and now non-Latin characters in both the local part and the domain.

A sensible approach for a business website:

• Check that there is exactly one @ symbol, something before it, and a domain after it containing at least one dot.
• Trim whitespace and lowercase the address before storing, while remembering that only the domain part is officially case-insensitive.
• Use your framework's built-in email rule rather than a regex you found online. Laravel, Django and Rails all ship with reasonable ones.
• Do not block plus addressing such as name+shop@gmail.com. It is valid and people use it deliberately.
• Do not maintain a list of allowed domain extensions. New ones appear constantly, and .in, .co.in, .org.in and .store are all perfectly ordinary.

Catching typos without rejecting anyone

A gentle suggestion beats a hard block. If someone types gmial.com or yaho.com, show a hint such as "Did you mean gmail.com?" with the corrected version as a one-click option, and still allow them to continue. For anything important, a confirmation email is the real test: if it does not arrive, the address was wrong.

Some teams check that the domain has MX records before accepting the address. That is a reasonable extra step for order forms, but do it asynchronously so a slow DNS lookup never blocks the submission.

PIN codes: six digits, but not any six digits

An Indian PIN code is exactly six digits, and the first digit falls between 1 and 8, since 0 and 9 are not used as the first digit of a postal circle. So the basic rule is simple: strip spaces, require six digits, and reject a leading 0 or 9.

Beyond the shape, decide how much you care about the code being real:

• Shape check only: fine for a contact form or a newsletter signup.
• Lookup against a PIN code dataset: useful for autofilling city and state, which saves the customer typing and reduces address errors on deliveries.
• Serviceability check: for an online store, the more valuable question is whether you deliver there. Show the answer immediately, with an estimated delivery window, rather than after checkout.

Store PIN codes as text. Storing them as numbers will eventually drop a leading digit or apply thousand separators in an export, and spreadsheets are notorious for this.

Be lenient on input, strict on storage

The pattern that ties all three fields together is a small pipeline: trim, normalise, validate, store canonically, display formatted.

Concretely, that means a visitor may type "+91 98765 43210", you store "+919876543210", and you display it back as "+91 98765 43210" on the confirmation screen. Everyone gets what they need, and your database stays comparable so that duplicate detection and messaging both work.

Apply the same rules everywhere the data enters your system: the website form, the admin panel, bulk imports from a spreadsheet, and any API. Imported data is usually the messiest, because it was typed by people who were not thinking about your validation at all.

Test your form with real-world input

Before you call a form finished, submit this list and check what lands in the database: a number with +91 and spaces, a number with a leading zero, a landline, an address with a plus sign, an address on a .co.in domain, a PIN code with a trailing space, and every field left blank. Fix whatever breaks, then run the same list again after your next site update, because validation rules quietly change when plugins update. Our website development team applies these checks as standard when building enquiry and checkout forms.

Frequently asked questions

Should I ask for the country code separately?

If you sell only within India, a single field with a fixed +91 prefix shown beside it is simplest. If you have international customers, use a separate country selector that defaults to India and store the result in E.164 format.

Can I verify a mobile number is real without an OTP?

Not reliably. Format checks confirm the shape only. If the number matters, for example for delivery updates, an OTP or a WhatsApp confirmation is the only dependable method.

Is it safe to auto-fill city and state from a PIN code?

Yes, and it reduces errors, but always leave the fields editable. Some PIN codes cover several localities and customers know their own address better than your dataset does.

How long should text fields allow?

Set generous but finite limits: around 100 characters for a name, 254 for an email address as the specification allows, and 20 for a phone field to accommodate the plus sign and spacing. Enforce the limit on the server as well as in the HTML.