The Contact Picker API shares only chosen people
A contact list is one of the most sensitive collections on a personal device. It can contain family members, clients, colleagues, phone numbers, email addresses, and physical addresses. Native apps have long asked for broad address-book permission, sometimes gaining ongoing access to every entry even when the user wanted to share only one person.
The Contact Picker API takes a narrower approach for the web. A website can open the device's trusted contact interface, but the person chooses which contacts and fields to share. Access is one-off rather than persistent, so the site must ask again the next time it needs information.
What a website can request
A supporting page uses navigator.contacts.select() and specifies the properties it needs. Depending on the browser and device, those properties may include names, email addresses, telephone numbers, physical addresses, or icons. The browser then displays a system-controlled picker.
The MDN Contact Picker API guide lists practical uses: choosing someone to message, selecting a number for a voice call, or finding which chosen contacts already use a service. The API does not give JavaScript an unrestricted view of the address book before the user makes a selection.
Websites can check supported properties first and request only the fields required for the task. A delivery form might need a name and address. A calling app might need a name and phone number. Asking for every available field “just in case” defeats the purpose of selective disclosure.
Why the picker is safer than blanket access
The browser or operating system owns the selection interface. The website receives only the entries the person confirms, not the complete list behind the picker. It cannot silently search other contacts or learn how many people are stored on the device.
The W3C Contact Picker specification describes the model as one-off access. Permission is not retained for future calls. That deliberate friction protects against gradual address-book harvesting and makes every disclosure connected to a visible user decision.
This is stronger than a single permanent “allow contacts” switch. A person's relationship with a site can change, and the appropriate recipient can differ every time. Requiring a new choice keeps consent specific to the current action.
Where the API is allowed to run
The Contact Picker API is restricted to secure HTTPS pages in the top-level browsing context. An advertisement or unrelated third-party iframe cannot invoke the picker independently. The call also requires user interaction, such as pressing a button, so a page cannot open it immediately on load.
These rules align with the model in our practical guide to browser permissions. Powerful capabilities should appear in context, after an understandable action, with a useful path forward when the user declines.
MDN marks the feature experimental and not Baseline because it is unavailable in some widely used browsers. Developers must detect support and provide a manual entry form. A contact-sharing feature should never block someone simply because their browser does not implement the picker.
Selection does not end the privacy obligation
After the user confirms a contact, the selected data enters the webpage's memory. The browser's picker can limit collection, but it cannot control what the site later sends to its servers, stores in analytics, or shares with partners. Product design and privacy policy still matter.
A responsible site should state why each requested field is necessary, use it for that purpose, and retain it only as long as needed. Contact details should not be added to marketing lists or uploaded for social matching unless the user clearly chooses that separate action.
The distinction resembles storage controls discussed in browser storage partitioning. A browser can enforce useful technical boundaries, while the application remains accountable for data it legitimately receives inside those boundaries.
Contact data can reveal more than one person
Sharing a contact discloses information about somebody who may not be present to consent. A phone number or address belongs to the selected person, not only to the device owner. That calls for restraint even when the picker interaction is valid.
Applications should avoid requesting physical addresses for a simple invitation, icons for a phone call, or multiple contacts when one is enough. They should also make the next step visible before selection: “Choose a recipient for this message” is clearer than “Sync contacts.”
Bulk matching deserves particular care. A service that wants to discover friends could tempt users to select many entries, then upload identifiers to a server. The API's selective model does not automatically make that practice privacy-friendly. Hashing phone numbers may reduce casual exposure, but stable hashes can still be matched and profiled.
How developers should design the flow
- Ask only after the user starts an action that clearly needs a contact.
- Request the smallest set of supported properties.
- Explain whether selected data stays on the device or reaches a server.
- Provide manual entry when the API is unsupported or cancelled.
- Treat cancellation as normal and avoid repeated prompts.
- Do not reuse selected details for advertising or unrelated analytics.
- Delete temporary contact data when the task is complete.
Site owners should also keep the feature out of embedded third-party code. Our article on Permissions Policy and browser privacy explains how top-level sites can control which documents are eligible to use sensitive capabilities.
What users should look for
Before opening the picker, confirm that the domain is the service you intended to use. Read the page's explanation and notice which fields it requests. In the system picker, select only the person or people needed for the task. Cancel if the purpose is vague or the request appears on an unrelated page.
Because the permission is not persistent, choosing a contact once does not give the site a permanent window into future address-book changes. However, information already submitted to the site may remain in its systems. Browser controls cannot retract data after transmission.
The Contact Picker API offers a thoughtful pattern for personal-data access: the browser keeps the complete collection hidden, the user selects a narrow subset, and the grant expires immediately. The design does not remove the need for trust, but it makes the decision more specific, visible, and proportionate to the task.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.