You type your number, the form rejects it, and there is no clue as to which part it disliked. You try it with the zero. You try it without. You try it with a plus sign, then with two zeros. One of these eventually works, or none of them does, and either way you finish with no idea what happened.
TL;DR: A rejection on its own does not tell you what number the service ended up with, so guessing at the stored value from an error message is not a sound approach. Look at what the form is actually showing you — the country selector, the field’s own hint, and any confirmation displayed back to you. There is no universal rule for dropping a leading zero or for swapping a plus sign for two zeros; both vary by country. And a number that looks correctly formatted is still not proof that it can be reached or that a given service will accept it.
A rejection does not tell you what the service stored
This is the part worth resisting, because it feels like detective work and is mostly guessing.
A generic rejection does not establish how your input was interpreted, whether anything was saved at all, or why it failed. Some forms check the shape in the browser and refuse before anything is sent or stored. Some echo back what they read. Others say only that the number is invalid. The same bare message is consistent with a number recorded exactly as you meant it and refused for an unrelated reason, with one that lost a digit, and with one read against a different country. Which of those applies is not something the message alone settles.
What you can do instead is look at the things the form does show.
Where to look instead
The country selector. International forms commonly split the number in two: a country or dialling-code control, and a field for the rest. These are separate inputs, and it is entirely possible to have the right digits against the wrong country. The country you pick changes how the remaining digits are read, and the libphonenumber project’s FAQ describes exactly this dependence — the region supplied governs how leading digits are interpreted, including whether they are taken as a country calling code at all.
The field’s own hint. Placeholder text and format examples indicate what shape that form expects. This is observable guidance rather than proof that the interface matches what the service stores, and it does not establish that the example is correct for your country. Where a hint is missing or looks inconsistent, the service’s own help and your number provider’s statement of the number’s international form are better references than a remembered rule.
Any confirmation shown back to you. Some services display the number they are about to use, often partly masked. Read it. Shown in full it is strong evidence of what the interface holds; masked, a matching final few digits is a clue rather than a unique identification. Either way it reflects what the form is displaying, which is not by itself a guarantee about what is stored behind it.
The account’s own settings, where you can reach them. If you are signing in or recovering rather than registering, a security or profile screen may show the number on file, and that is a better source than anything inferred from an error. It is only available when the account exists and you can still get into it.
The leading zero has no universal rule
The advice people repeat — drop the leading zero when you add the country code — is true in many countries and false in others, and applying it as a law produces wrong numbers.
The libphonenumber project maintains a list of falsehoods programmers believe about phone numbers, and one of them is precisely the belief that a leading zero in a domestic number can always be discarded when dialling from abroad. Italy supplies its counterexample: it describes a number that since 1998 carries its prefix as part of the number, illustrated as 012345 domestically and +39012345 internationally with the zero retained. Those digits are an illustration from that document rather than a number to dial, and the point is that such numbers exist — not that every Italian number behaves this way.
The same list addresses the other half of the folklore. The plus sign in an international number cannot always be replaced by 00, because the international call prefix varies by country — Japan’s is 010, not 00.
The practical consequence is not that you need to learn the rules for every country. It is that a remembered rule is a poor substitute for two better references: the instructions the field itself gives, and the way your number provider states that number in international form. Entering what the provider states, rather than a version you have transformed, avoids inventing a number that was never yours.
What the symptom points at
| What you observe | What it is consistent with | What to inspect |
|---|---|---|
| Form rejects the number immediately | Possibly a shape this form does not accept; it does not establish that nothing was sent | The field’s hint or placeholder, and the country selector |
| Form accepts it, but no code ever arrives | Any number of things, including a stored number that is not yours | The destination the service displays, and whether that line can receive messages |
| Rejection only when you include the country code | The field may already be handling the country separately | Whether a country control exists beside the field |
| Accepted after correcting the selector | The correction addressed one observable problem | Whether a code now arrives; the correction alone does not settle it |
| Rejection only when you omit the leading zero | This may be a country where the zero is retained | The form’s own example, not a general rule |
| Accepted, code arrives, but a later attempt fails | Not necessarily a format problem at all | What the service says about that code’s validity |
Two situations worth walking through
Both are hypothetical, written to show the reasoning rather than to report a case.
The country that was never changed. Someone travelling enters their mobile number into a form whose country selector shows the country they are currently in rather than the country the number belongs to. The digits are correct. The form may refuse them, or may accept them and read them against that other country. Neither outcome on its own reveals how the digits were normalised. What is inspectable is the selector sitting next to the field and any confirmation shown before sending. Setting the selector to the number’s own country and re-reading the confirmation is the correction to make; whether it resolves the whole problem is something the next attempt shows rather than something the correction guarantees.
The zero that was removed on principle. Someone holds an Italian number whose leading zero is genuinely part of its international form, and drops that zero when adding +39 because the familiar advice says to. What they have entered is no longer the same number. If the form refuses it, they may spend a while trying further transformations of the altered digits. If the form accepts it, acceptance does not reveal what the service made of it, and a code may or may not reach them. The check is the same either way — read back whatever the service shows, and compare it against the number as their own provider states it in international form, rather than against a rule of thumb.
Why a correct format is not a guarantee
Two separate things get read into a well-formed number, and neither follows.
A valid format does not mean the number is reachable. The libphonenumber FAQ is explicit that a valid range is one from which numbers can be assigned by carriers, and states plainly that the library should not be relied on to determine whether a number is currently assigned to a specific person and reachable. A number can be perfectly well-formed and simply not in service.
A correct number does not mean a service will accept it. Platforms apply their own rules on top of format. A number one service takes without comment may be refused by another, and platform policy is one possible reason among several rather than an explanation of every difference between services. Where a service returns a specific message about a number not being usable, what that kind of rejection does and does not mean is worth reading before changing anything.
The reverse also holds, which is unintuitive: the same falsehoods list notes that an invalid number will not necessarily fail to reach an endpoint, giving dialling cases where extra digits are ignored in some jurisdictions. So a call connecting is not proof that the number was correct. That example is about dialling, and this guide does not extend it to how any particular service routes a text message.
When the format was not the problem
If the number is entered correctly and confirmed, and a code still does not arrive, the question has moved on.
It may be that the line addressed cannot receive messages at all, which is the case with a data-only plan. It may be that the code went somewhere other than SMS, since a screen showing your number does not tell you the channel. It may be that the code arrived and would not enter the field, which is a separate problem with its own checks. Or the code may have arrived and expired, in which case what a temporary number can do about a second one is the relevant reading.
Limitations of this guide
This uses the libphonenumber project’s published material to show that common number transformations are not universal. It does not use that project as a description of how any service validates numbers, and nothing here implies we use that library.
Country-specific numbering rules are not listed here, and deliberately so: this is not a catalogue of national numbering plans. Where the correct international form of your own number is unclear, the number provider that issued it and the service’s own help are the places to resolve it.
This guide cannot tell you what a particular service stored. Read what the service displays as useful guidance, not as proof of its internal storage, and do not deduce that storage from a rejection.
Our help answers cover the ordering side, and a support ticket is the route for anything specific to an order you placed with us.
FAQ
Can I work out what number the service saved from the error message?
Not from a generic rejection, and that is the main thing worth taking away. Such a message does not tell you how the input was read, whether it was saved, or what failed. Some forms do echo back what they interpreted, and where that happens it is useful. Where it does not, read the destination the service displays, or the number on the account’s settings screen if you can reach it, rather than deducing it from the error.
Should I drop the leading zero when I add my country code?
Sometimes, and there is no rule that always holds. The libphonenumber project lists the belief that a leading zero can always be discarded as a falsehood, and gives Italy as a counterexample where the zero is retained in the international form. Follow the example the form itself shows rather than applying a remembered rule.
Is 00 the same as a plus sign?
Not everywhere. 00 is a common international call prefix but it varies by country — Japan uses 010. If a field asks for international format, the plus form is the safer thing to enter.
The form accepted my number, so it must be correct. Is that right?
Acceptance means the number passed that form’s checks. It does not establish that the number is yours, that it is currently assigned, or that it can receive messages. libphonenumber’s own FAQ warns against treating validity as evidence that a number is assigned and reachable.
My number works for calls but a service refuses it. Why?
Services apply their own policies on top of format, and those are separate from whether a number is well-formed. Policy is one possible reason a number accepted elsewhere is refused here; it is not a diagnosis of every such difference. Read the specific message the service gives, since some of them distinguish quite different situations.
I entered the number wrongly and it was accepted. What now?
Correct it where the service asks for it — in the flow you are in if it offers that, or in the account’s settings if you can reach them — then start a fresh send. If the service will not let you change the number without passing a check you cannot pass, that has become a recovery problem for that service rather than a formatting one.