Beware When Pasting Phone Numbers Copied from Contacts

Have you ever had trouble pasting a phone number copied from Contacts into a web form? This may not be a common problem, but it is one that TidBITS reader Dave Fultz solved after a frustrating struggle with an online order form.

Dave tried to order a package in France, and the form requested a mobile phone number from the delivery address. To make sure he had it right, he copied it from Contacts and pasted it into the form, but when he clicked Submit, the form failed to verify. He tried different formats for the telephone number – in France the leading zero must be included in the ten-digit number when calling within the country, but omitted when calling from abroad – to no effect. Pasting the number into some online verification services also failed. Paste as plain text also made no difference.

So Dave texted his friend the number, which worked fine, and asked her to send him the number exactly as she would give it to a Frenchman. It looked the same as his version, but when he copied and pasted the number from the Message Thread, the form accepted it! What is happening?

Dave intended to use a Python script in Terminal to compare the number he had from Contacts with the one his friend sent, but when he pasted his number into Terminal, the problem immediately revealed itself , as you can see in the highlighted text in my test below, which shows extra characters on either side of the phone number.

It turns out that Contacts on the Mac wraps all phone numbers in two zero-width (and therefore invisible) Unicode characters: U+202D (LEFT-TO-RIGHT OVERWRITE) and U+202C (POP DIRECTIONAL FORMATTING). Dave speculated that those characters exempt the phone number from the surrounding text flow direction, which would be right to left with Hebrew and Arabic, for example.

Contacts seems to store those characters with the phone number, but since they’re zero-width, there’s no way to avoid selecting them that I could find. I don’t believe Contacts adds those characters to the numbers as part of the copy, because if you select some characters in the middle of a number and then copy and paste them into Terminal, the invisible characters won’t be present. They are also unique to the phone number fields; a number stored in the Notes field will not have it either. Finally, the problem is limited to contacts on the Mac; the problem does not affect phone numbers copied from an iPhone or iPad in my test. (Some subsequent research has a Ask another thread (which describes the issue – which has been reported to Apple as a bug – and confirms that it still exists in macOS 13.1 Ventura.)

Why aren’t these characters causing more problems? When developers design programs that accept data, they usually create import filters which filters out unwanted data. A phone number field has no reason to accept invisible punctuation, so it is good programming practice to abandon it. If nothing else, filtering user input is an essential security practice because attackers will often try to enter a system data to inject malicious code or to cause buffer overflows that can be exploited.

So while it may seem odd that Apple designed Contacts to wrap every phone number in those zero-width characters, it protects phone numbers pasted in right-to-left text flow from being altered. However, it doesn’t seem necessary for Contacts to do this for all Mac users. Apple can try to identify when this will make sense – perhaps only when the user has enabled a right-to-left language in macOS’s Language and Region settings.

Practically speaking, if you encounter a situation where a phone number copied and pasted from Contacts does not work as expected, the simplest solution is to type the number manually. You can also paste it into Terminal and just copy the phone number again, avoiding the extra Unicode characters on either side.

If you run into this problem often and want to pick up some geek points, you can create a Keyboard Maestro macro that automatically strips out those extra characters. Fearing the need to type numbers over like an animal, Dave did just that, so you could use its macro as a starting point for whatever workflow makes sense to you.

Or you can do what I do and leave Contacts for los Cardhopwhich does not suffer from the problem and is much more pleasant to use (see “Cardhop puts contacts front and center,” October 18, 2017, and “Cardhop 2.0 with Fantastical in Flexibits Premium,” 27 May 2021).