Structured data mastery

JSON-LD vs. Microdata vs. RDFa in 2026

Three syntaxes for the same Schema.org vocabulary. Why JSON-LD won in practice, the cases where the other two still ship, and the failure modes from mixing formats on the same page.

9 min read Updated May 10, 2026

Schema.org is the shared vocabulary AI surfaces and search engines read to understand a product page. The vocabulary is independent of the syntax that carries it — three formats can carry exactly the same Schema.org assertions. The three are JSON-LD, Microdata, and RDFa.

In 2026, JSON-LD has won. Google, OpenAI, Perplexity, and Microsoft all recommend it. Most published comparisons between the three formats treat them as roughly equivalent options; they are not. This guide names what the three formats are, why JSON-LD won, the narrow cases where Microdata still legitimately ships, and the failure modes that show up most when a catalog runs more than one format on the same page.

This guide assumes some familiarity with Schema.org. The companion definitional guide is Product schema for Shopify — start there if the vocabulary itself is unfamiliar.

What the three formats are

The same Product assertion (name, description, price) expressed in each format:

JSON-LD — a separate JSON block in the page <head>:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wool Runner",
  "description": "A weatherproof merino wool sneaker.",
  "offers": {
    "@type": "Offer",
    "price": "98.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Microdata — annotations on existing HTML elements:

<div itemscope itemtype="https://schema.org/Product">
  <h1 itemprop="name">Wool Runner</h1>
  <p itemprop="description">A weatherproof merino wool sneaker.</p>
  <div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
    <meta itemprop="price" content="98.00" />
    <meta itemprop="priceCurrency" content="USD" />
    <link itemprop="availability" href="https://schema.org/InStock" />
  </div>
</div>

RDFa — similar to Microdata, with a different attribute syntax inherited from the broader Linked Data ecosystem:

<div vocab="https://schema.org/" typeof="Product">
  <h1 property="name">Wool Runner</h1>
  <p property="description">A weatherproof merino wool sneaker.</p>
  <div property="offers" typeof="Offer">
    <meta property="price" content="98.00" />
    <meta property="priceCurrency" content="USD" />
    <link property="availability" href="https://schema.org/InStock" />
  </div>
</div>

All three assert the same thing. From a Schema.org-vocabulary perspective, an AI surface parsing them should produce identical extracted structured data.

Why JSON-LD won

The official position from Google has been “JSON-LD is the recommended format” since the structured data documentation update around 2015–2016. That recommendation has held and intensified through every AI surface that has launched since.

Five practical reasons:

1. Separation of concerns. JSON-LD lives in a <script> block. It is independent of the page’s visible HTML structure. Microdata and RDFa annotate visible HTML, which means structural changes to the page (a redesign, a template refactor, a CMS migration) routinely break the structured data without anyone noticing. JSON-LD survives front-end refactors.

2. Server-side templating is easier. A backend producing a JSON-LD block emits one cohesive object the developer can reason about. Producing equivalent Microdata or RDFa requires threading attribute by attribute through HTML the templating engine is producing for visual rendering — every attribute is a chance to mis-nest, drop, or duplicate.

3. Validation tools are simpler. A JSON-LD block can be copied into a validator as a single unit. A Microdata or RDFa page has to be served via URL or have its full HTML pasted in, and the validator’s reading of the structure depends on the exact HTML hierarchy.

4. Edge cases break Microdata more often. Nested types (Product containing Offer containing Seller) are clean in JSON-LD and fragile in Microdata, especially when the visual rendering doesn’t naturally nest the elements. RDFa is slightly better than Microdata on this front but worse than JSON-LD.

5. JSON-LD doesn’t pollute the visible HTML. The accessibility and styling community broadly prefer keeping structural metadata out of class names and ARIA attributes. JSON-LD is invisible to visual rendering; Microdata adds attributes that are sometimes mistakenly used as CSS hooks.

JSON-LD, Microdata, and RDFa surface compatibilityA comparison matrix showing the three structured-data formats and their support across the major AI commerce surfaces (Google, OpenAI, Perplexity, Microsoft, Anthropic). JSON-LD is recommended on every surface; Microdata and RDFa are supported but not recommended.FORMAT × SURFACEGOOGLEOPENAIPERPLEXITYMICROSOFTANTHROPICJSON-LDRecommendedRecommendedRecommendedRecommendedRecommendedMicrodataSupportedLikely parsedLikely parsedSupportedLikely parsedRDFaSupportedLikely parsedLikely parsedSupportedLikely parsedSurface positions sourced from each vendor’s public documentation. “Likely parsed” means undocumented but expected — confirm against the surface’s own guidance for production use.

The matrix is what the practical evidence supports. JSON-LD is the recommendation everywhere it is documented; the other two formats are nominally supported by every parser that supports Schema.org but get less explicit attention in the AI surfaces’ own guidance.

Where the other two still ship

Three legitimate reasons a catalog runs Microdata or RDFa in 2026:

Legacy CMS templates. A Drupal or older WordPress installation may emit Microdata or RDFa through plugins that predate Schema.org’s JSON-LD preference. Rewriting the templates to emit JSON-LD is straightforward but non-trivial; if the catalog is small and the existing Microdata is valid, the cost-benefit of rewriting may not clear.

Server-side rendering on dynamic pages with strict bundle budgets. A page rendering a long list of items (a search result, a collection page) emitting JSON-LD for every item produces a large <script> block. Annotating the existing HTML with Microdata can sometimes be cheaper in bytes. In practice, most catalogs don’t hit this constraint hard enough for it to matter.

Generic Schema.org consumers outside the AI commerce category. Niche Linked Data consumers (academic graph tools, government data pipelines, semantic web aggregators) sometimes prefer RDFa. If a catalog has downstream consumers in this category, RDFa may be worth maintaining alongside JSON-LD.

For most ecommerce catalogs none of these reasons apply, and the right pattern is JSON-LD only.

The two formats on the same page (often broken)

The most common structured-data issue on a Shopify catalog is not “no structured data” — it is “too much structured data, in conflicting formats, with no clear authoritative source.” The typical pattern:

  1. The Shopify theme emits a Product JSON-LD block.
  2. A SEO app the merchant installed also emits a Product JSON-LD block (often with different property values).
  3. The theme uses Microdata on the visible HTML elements for legacy reasons.

An AI surface or a Google crawler finds three structured-data representations on the page. Which one wins is implementation- defined and unstable.

Failure modes from this:

The fix is to consolidate. Pick one source of truth — usually the theme’s JSON-LD — and remove the others. If a SEO app’s output is desired, disable the theme’s emission, not the other way around (apps tend to have more configurable property coverage). Verify with view-source and the Schema Markup Validator after.

See Validating structured data for the validation discipline.

Specific format-by-format quirks

JSON-LD: the @context declaration. Use "@context": "https://schema.org" (HTTPS). Some older code uses http://schema.org; both forms are widely accepted by parsers and there has been active community discussion about which is preferred, but HTTPS is the form Schema.org’s own documentation uses and avoids mixed-content warnings on some validators.

JSON-LD: @type arrays. A product that is both a Product and a more specific type (e.g., IndividualProduct) can be expressed as "@type": ["Product", "IndividualProduct"]. This is valid Schema.org and parsers handle it; some older Microdata implementations cannot express multi-typing as cleanly.

Microdata: itemref attribute. Microdata’s itemref attribute can pull properties from elsewhere in the page into a single item. This is the workaround Microdata offers for non-contiguous data, but it is rarely used correctly and tends to make parsers (and humans) unhappy. Prefer co-located markup or move to JSON-LD.

RDFa: vocab vs prefix. RDFa supports two ways of declaring the namespace. vocab="https://schema.org/" is the simpler form and matches the Schema.org convention; prefix="schema: https://schema.org/" is more general but more verbose. Use vocab unless you have a reason to mix vocabularies.

Operational recommendation

For a new build, an existing migration, or any greenfield work: use JSON-LD only. Emit it server-side from the page template. Validate against the Schema Markup Validator and the Rich Results Test on a sample page per template. Audit periodically that no app or plugin has started emitting a competing block.

For an existing catalog running Microdata or RDFa: the migration to JSON-LD is straightforward but non-trivial. Treat it as a quarterly project. The intermediate state — both formats running in parallel — is acceptable for a few weeks but should not be the steady state.

What this guide is part of

Related