So far, everyone is focusing on the JSON vs regex thing, but that's not the worst of the criticisms leveled here. Not being able to use the +44 prefix, or format the number with dashes are stunningly obvious usability problems that honestly should not have made it out of QA.
You'll see the same thing on different sites with credit card numbers. See, every credit card issuer uses a scheme called an "issuer identification number" to tell you what type of card it is. And, there's a list of them [0]. So, for instance, I can tell that any valid credit card number that starts with 4 must be a Visa. So, why ask me what type of card it is, when you can figure it out yourself?
Those rare sites where you actually want to put your Social Security number in have these sorts of issues, too. Some of them require dashes, some of them don't. Some of them will only allow you to enter 9 characters, but won't tell you not to use dashes. It's infuriating, really. And, any site where you enter an account number can potentially have these types of issues.
It's not like being just a little more flexible with input formatting is a major feature with huge implementation costs and security risks, either. We're talking about failing to take a few minutes' thought in order to be a little more kind to the user, and that's just inexcusable, IMO.
---
[0]: https://stevemorse.org/ssn/List_of_Bank_Identification_Numbe...
Just in case somebody considers implementing phone number parsing and normalizing: Just don't and use Googles libphonenumber, which offers solid, ready to use implementations in various languages (there also exist ports for other languages too): https://github.com/google/libphonenumber/