JSContact and RFC 10050: Contact Data Exchange for SEOs

JSContact is the JSON counterpart of vCard. RFC 9553 defines it as a JSON representation of contact data, and its central object is the Card. A Card holds a name, email addresses, phone numbers, postal addresses, online services and the organization a person belongs to. The same object can describe a person, a company, a group or a location, because each Card carries a kind property that says which one it is.

This guide is written for technical SEOs who run into the term in a client meeting, a CRM export or a standards feed and want to know where it sits relative to the structured data they audit every week. It covers what the format is, how it converts to vCard, how RFC 10050 relates to the JSContact documents, and what changes in your work. The short version: it changes very little, and knowing why saves you from a few wrong assumptions.

What JSContact is and why it exists

vCard has existed for decades. The version in current use, vCard 4.0, is specified in RFC 6350. It is a line-based text format with its own escaping rules, parameters and folding of long lines. Reading it takes a dedicated parser, and writing it by hand is error-prone. Over the years implementers also added properties of their own, so two systems that both claim to support vCard often disagree on what a given card means. A contact exported from one address book can arrive in another with fields dropped or misplaced.

JSON removes the first problem directly. Nearly every web API already sends and receives JSON, and every mainstream language ships a parser for it, so a Card can travel through the same pipes as the rest of an application’s data. JSContact also fixes the structure inside the object. A name is split into typed components, and a collection such as the email list is a map with explicit identifiers. Software no longer has to guess where one entry ends and the next begins.

The two formats are expected to coexist. A company that stores contacts in vCard files today does not have to migrate, and a service that speaks JSON can still exchange data with vCard-based clients through a conversion layer. That conversion layer is the subject of the next section.

How a JSContact Card maps to vCard

RFC 9555 defines how a JSContact Card converts to a vCard and back. It is a mapping specification. It describes how to carry the meaning of a card from one format to the other, and it does not promise that a round trip returns identical bytes.

The simple fields line up in an obvious way. The name of a person corresponds to the vCard N and FN properties, email addresses to EMAIL, phone numbers to TEL, organizations to ORG and postal addresses to ADR. The structural difference shows up immediately. vCard repeats a property once per value, one line after another, while JSContact keeps related values together in a map keyed by an identifier. Each entry also carries its own context, such as work or private, which vCard expresses through parameters on the property.

The interesting cases are the ones where one format has a concept the other lacks:

• Properties that exist in vCard but have no first-class JSContact field need a place to live in the converted card, so a converter can restore them later.
• Features that exist only in JSContact, such as values with language variants, need a rule for how a vCard output should represent them.
• Parameters that one format defines and the other does not have to be moved to an extension location or dropped.
• Free-form vCard text sometimes lands in a spot where JSContact expects a structured value, so the converter must interpret the string or keep it as written.

The exact names of these properties and the rule for each case are in the RFC 9555 text. Take them from there and not from a summary, including this one, because the field-level table is where converters differ. Whether a particular tool loses information depends on which properties your data uses and how completely that tool implements the document. If a vendor advertises lossless conversion, take a sample of your own cards, convert them both ways and compare the results against the property list in RFC 9555.

Two companion documents complete the family. RFC 9554 defines vCard extensions that JSContact needs, and RFC 9555 depends on them when it converts. Anything you read about JSContact as a format traces back to these three numbers.

Where RFC 10050 fits

RFC 10050 is the number in this guide’s search topic, and the RFC Editor publishes its header at rfc-editor.org/rfc/rfc10050. That header decides how the document relates to the JSContact family. It lists a title, a publication date, a status, and the Updates and Obsoletes fields. An Updates or Obsoletes line that names RFC 9553, 9554 or 9555 places the document in the JSContact family, and the abstract then states what it changes: the Card object, a registry, or the conversion rules.

Until you have read that header, quote RFC 9553 for anything about the Card format itself. It is the base specification, and a later document that updates it refers back to it. The status line matters as well. Proposed Standard, Informational and Experimental carry different weight, and a vendor that says it supports the RFC should be able to tell you which one applies.

For a technical SEO, the useful question is what a change to this family would reach. An update to the JSContact documents changes what the developers of contact systems implement: CRMs, address books, mail servers and the libraries between them. It does not change the HTML of your pages, and it does not change the structured data that Google reads from them. That remains schema.org vocabulary, which the next section describes.

What JSContact means for SEO work

On a web page, the vocabulary that matters is schema.org. ContactPoint and Organization describe a business there. You embed them as JSON-LD or microdata, and a crawler reads them from the HTML. Google’s Search Central documentation explains Organization markup and lists the properties it reads. The vocabulary exists so that a search engine can connect a page to a named entity with a phone number, an email address and support hours.

JSContact has a different job. A Card is a JSON object that one application hands to another: a CRM exporting a customer record, a mail server syncing an address book, a contacts app importing a file. The data travels over an API between systems that both expect the format. No public web page and no crawler takes part in that exchange.

Both are JSON, and both carry names, emails and phone numbers, so a client who heard structured contact data in a meeting may assume one covers the other. It does not. A ContactPoint on your contact page describes the page to a search engine. A JSContact Card describes a person to a mail client.

Publishing a Card on a page as a JSON-LD block therefore gains nothing. JSON-LD works because search engines read the vocabulary declared in its context, and schema.org is the vocabulary they read. A JSContact object has no such agreement behind it, so the block would sit in your HTML unread. It could also expose the personal details of a named individual to every scraper that visits.

On Google specifically, the Search Central pages describe schema.org markup, and JSContact does not appear in the Organization documentation. Nothing published says how Google treats the format internally, so this guide makes no claim about it. Nothing published gives you a reason to act on it either.

The practical gain is vocabulary. If a client runs a CRM, a shared address book or a JMAP-based mail service, the people who maintain those systems may bring up JSContact, vCard or contact export. You can place those terms now: they describe how contact records move between internal tools, and they stay outside your audit scope.

When the same client asks why the phone number on the site differs from the one on their Google Business Profile, you are back in familiar territory. That is a ContactPoint and local data consistency problem, and you check it the way you always have, by comparing what the pages say with what the other listings say.

Limits, personal data and a step for today

JSContact does not change your rankings. The same applies to any RFC that updates it: a standard for moving address-book data between systems gives a search engine no reason to reward your pages. Anyone who sells it as a ranking tactic is guessing. Pasting a Card into a page costs effort and returns nothing.

Personal data adds a second limit. A contact card can hold names, personal phone numbers, home addresses and email addresses. If a crawl or an export touches pages or files that contain such data, the GDPR or a comparable national law may apply to how you collect, store and share it. This guide makes no legal claim about what your case requires. Before you export contact fields from a client site into a spreadsheet or a shared report, ask the client’s data protection contact what they allow. Keeping crawl data on your own machine reduces the number of places that data can leak from, and it leaves the legal question open.

The conversation around JSContact can also reach your audits through one door: the structured data you inspect on pages that print contact details. That is where a mismatch costs you something, and it is a check you can run today. Open your contact page and the homepage, and view the JSON-LD in the source. Confirm that the Organization name, telephone number and email match what visitors see on the page, and that any ContactPoint carries a correct contactType. Then run the same check on the other templates that print contact details, such as the footer, location pages and the about page. Fix mismatches in the markup first, because those are the ones search engines can read.

Open your contact page source now and compare its JSON-LD telephone number with the number printed on the page.