Inconsistent Phone Number Formatting Across Country Codes in PhoneInput Component

[sahil5343]

Found a bug? Please fill out the sections below. 👍

Issue Summary

There is an inconsistency in phone number formatting across different country codes in the phone input component. The bug is caused by the way phone numbers are parsed and formatted using the libphonenumber-js library without enforcing a standardized formatting pattern. This leads to unpredictable spacing and grouping of numbers depending on the country code.

Steps to Reproduce

1. Go to the phone number input field in the app (packages/features/components/phone-input/PhoneInput.tsx).
2. Enter a phone number with a country code, e.g., +58XXXXXXXXXX.
3. Observe the format of the number displayed.
4. Change the country code to +1 or +44 and enter the respective number.
5. Compare the displayed format across different country codes.

Actual Results

• Phone numbers appear in inconsistent formats depending on the country code.
• Some country codes add extra spacing or different grouping of digits.
• The "+" prefix is always added, sometimes resulting in unexpected formatting.

Expected Results

• Phone numbers should follow a consistent, standardized format regardless of the country code.
• Ideally, the formatting should align with the E.164 standard or a uniform international format for all numbers.

Technical details

• Files involved:
  • packages/lib/formatPhoneNumber.ts
  • packages/features/components/phone-input/PhoneInput.tsx
• Code snippet causing the issue (from formatPhoneNumber.ts):

export const formatPhoneNumber = (phoneNumber: string) => {
  const parsedPhoneNumber = parsePhoneNumberWithError(phoneNumber);
  return parsedPhoneNumber?.isValid() ? parsedPhoneNumber.formatInternational() : phoneNumber;
};

• The issue occurs because:

  • PhoneInput.tsx automatically adds a "+" prefix to all numbers.
  • formatPhoneNumber relies on libphonenumber-js which applies different spacing/grouping rules per country code.
  • No standardized formatting pattern is enforced.

• Environment details:

  • Browser: [Add your browser version here]
  • Node.js version: [Add your Node.js version here]
  • No backend involvement — purely frontend formatting issue

Evidence

• Testing performed manually by entering numbers for multiple country codes (+58, +1, +44).
• Screenshots/videos should be attached to show the inconsistency (e.g., different spacing applied).

This bug is self-contained and limited to the phone input and formatting logic. Fixing it would significantly improve the consistency and user experience of the phone number input feature.

[linear]

CAL-6497

[CarinaWolli]

I agree that the PhoneInput fields needs some improvements. However, I am not sure about the points you listed.

PhoneInput.tsx automatically adds a "+" prefix to all numbers.

We want that. But I have one suggestion for improvement: We should allow the user type type the + themselves. At the moment, we automatically add it and the user can't type it

formatPhoneNumber relies on libphonenumber-js which applies different spacing/grouping rules per country code.
No standardized formatting pattern is enforced.

What's the issue with this? I'd say having spcacing/grouping depending on the country code is a good thing

[albin-baby-2002]

I agree with @CarinaWolli — there’s no need to change the spacing or grouping in how we display phone numbers. In fact, it’s good to keep it for readability.

What we should do is:

Display the number in the UI with proper grouping for clarity.

Store and send the value to the API in E.164 format.

It’s also good that we don’t allow users to remove the “+” sign — that ensures they either enter the correct country code or select it explicitly, which is essential for converting the phone number into E.164 format.

if we can agree on these points and the needs approval badge is removed i can work on this

[CarinaWolli]

Let's focus on the following two things:

1. Display the number in the UI with proper grouping for clarity
2. If possible, improve grouping. For example Austria phone numbers a grouped a bit odd:

I think the API side of it is fine