Beware When Pasting Phone Numbers Copied from Contacts

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

Dave was trying to order a package in France, and the form requested a mobile number at the delivery address. To ensure he had it right, he copied it from Contacts and pasted it into the form, but when he clicked Submit, the form failed verification. He tried different formats for the phone number—in France, the leading zero in the ten-digit number should be included when calling inside the country but omitted when calling from abroad—to no effect. Pasting the number into a few online verification services failed as well. Nor did pasting as plain text make any difference.

So Dave texted his friend at the number, which worked fine, and asked her to send him the number exactly as she would give it to a French person. It looked the same as his version, but when he copied and pasted the number from the Messages thread, the form accepted it! What was going on?

Dave was planning to use a Python script in Terminal to compare the number he had from Contacts with the one his friend had sent, but when he pasted his number into Terminal, the problem revealed itself instantly, 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 encloses all phone numbers in two zero-width (and thus invisible) Unicode characters: U+202D (LEFT-TO-RIGHT OVERRIDE) 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 instance.

Contacts appears to store those characters with the phone number, but since they’re zero-width, there’s no way to avoid selecting them that I was able to find. I don’t believe Contacts is adding those characters to the numbers as part of the copy because if you select a few characters in the middle of a number and then copy and paste them into Terminal, the invisible characters won’t be present. They’re also unique to the phone number fields; a number stored in the Notes field won’t have them either. Finally, the issue is limited to Contacts on the Mac; the problem doesn’t afflict phone numbers copied from an iPhone or iPad in my testing. (Some subsequent research turned up an Ask Different thread that describes the problem—which has been reported to Apple as a bug—and confirms that it still exists in macOS 13.1 Ventura.)

Why don’t these characters cause more problems? When developers design apps that accept data, they generally create input filters that filter out unwanted data. A phone number field has no reason to accept invisible punctuation characters, so it’s good programming practice to drop them. If nothing else, filtering user input is an essential security practice because attackers will often try to feed a system data to inject malicious code or to cause buffer overflows that could be exploited.

So while it seems weird that Apple designed Contacts to enclose every phone number in those zero-width characters, it does protect phone numbers pasted into right-to-left text flows from being changed. It doesn’t seem necessary for Contacts to do this for all Mac users, however. Apple could try to identify when it would make sense—perhaps only when the user has enabled a right-to-left language in macOS’s Language & Region settings.

Practically speaking, if you run into a situation where a phone number copied and pasted from Contacts doesn’t work as expected, the simplest fix is to type the number by hand. You could also paste it into Terminal and copy just the phone number again, avoiding the extra Unicode characters on either side. 

If you regularly ran into this problem and wanted to rack up some geek points, you could create a Keyboard Maestro macro that automatically stripped those extra characters. Peeved by the need to retype numbers like an animal, Dave Fultz did exactly that, so you could use his macro as a starting point for whatever workflow makes sense to you.

Or you could do what I do and rely instead on the contact management app Cardhop, which doesn’t suffer from the problem and is far more pleasant to use (see “Cardhop Puts Contacts Front and Center,” 18 October 2017, and  “Cardhop 2.0 Bundled with Fantastical in Flexibits Premium,” 27 May 2021).