JSON-LD vs Microdata: Which Format for Schema?

Every piece of Schema.org markup you write has to be encoded into the page somehow, and there are three ways to do it: JSON-LD, Microdata, and RDFa. The vocabulary is identical in all three — same types, same properties, same meaning. Only the encoding differs, and that difference turns out to matter a great deal for how maintainable your markup is.

If you are starting from scratch, the short answer is JSON-LD. But "Microdata is obsolete" is a claim that gets repeated more often than it is true, and the reasoning behind the recommendation is worth understanding before you rip anything out. For the wider context on what structured data does and which types to implement, see the complete guide to Schema.org structured data.

The same markup in three syntaxes

Here is a minimal Product in each format.

JSON-LD — a standalone script block, placed anywhere in the head or body:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Runner 3",
  "brand": { "@type": "Brand", "name": "Northpath" },
  "offers": {
    "@type": "Offer",
    "price": "129.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Microdata — attributes woven into the HTML that displays the content:

<div itemscope itemtype="https://schema.org/Product">
  <h1 itemprop="name">Trail Runner 3</h1>
  <span itemprop="brand" itemscope itemtype="https://schema.org/Brand">
    <span itemprop="name">Northpath</span>
  </span>
  <div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
    <meta itemprop="priceCurrency" content="USD">
    <span itemprop="price" content="129.00">$129.00</span>
    <link itemprop="availability" href="https://schema.org/InStock">
  </div>
</div>

RDFa Lite — the same inline approach with different attribute names (vocab, typeof, property):

<div vocab="https://schema.org/" typeof="Product">
  <h1 property="name">Trail Runner 3</h1>
  <div property="offers" typeof="Offer">
    <meta property="priceCurrency" content="USD">
    <span property="price" content="129.00">$129.00</span>
  </div>
</div>

All three produce the same parsed entity. All three are valid. All three are read by Google.

Why Google recommends JSON-LD

Google's structured data documentation names JSON-LD as the recommended format, and the stated reason is straightforward: it is easier to add and update, because it does not require interleaving annotations with the user-visible HTML.

That decoupling has several consequences in practice:

• Templates and markup evolve independently. A front-end change that restructures a product page cannot silently break a JSON-LD block. The same change to a Microdata implementation can, and nothing in the rendered page looks wrong when it does.
• It is generated, not authored. JSON-LD maps cleanly onto the data objects your server already has. You serialise a product object to JSON rather than sprinkling attributes across a view.
• It is reviewable. A JSON-LD block is a single contiguous artefact you can diff, lint, and validate as standalone JSON. Microdata for the same entity may be spread across two hundred lines of template.
• It handles entities with no visible representation. Properties like sku, gtin13, or @id references have no natural home in the markup. Microdata forces you to invent one with hidden <meta> and <link> elements — the awkward bits in the example above.
• It can be injected. When template access is restricted, a tag manager can add it. Microdata cannot be retrofitted that way without rewriting the DOM.

The honest case for Microdata

Microdata is not a legacy artefact and it is not penalised. It is a W3C-derived HTML specification, documented by Schema.org as a supported syntax, and parsed by every major search engine. Google has never signalled any intention to stop reading it.

It also has a genuine structural advantage: because the annotations sit on the elements that display the content, the markup and the visible content cannot drift apart. A price in a JSON-LD block can say $99 while the page renders $129 — a live Google policy violation, and one of the more common causes of manual actions. In Microdata, itemprop="price" wraps the actual rendered price, so the two are the same string by construction.

That guarantee is real, but it is not usually decisive, because the drift problem is better solved by generating the JSON-LD from the same server-side value the template renders. If both come from one variable, they cannot disagree either.

Where Microdata still makes sense:

• Existing implementations that validate. Migration is work with no ranking upside. If Search Console shows valid items and no errors, leave it.
• Static or hand-authored HTML where there is no data layer to serialise from and the content is written directly into the markup.
• Environments that strip script tags — some email templates, some CMS sanitisers, some AMP-era constraints.

RDFa: a fair hearing

RDFa Lite deserves a mention rather than a dismissal. It is a W3C Recommendation, it works with any vocabulary rather than just Schema.org, and it is the format of choice where structured data feeds a broader linked-data or semantic-web pipeline rather than a search engine.

For SEO specifically, it offers no capability JSON-LD lacks while carrying the same HTML coupling as Microdata. It is also the least common of the three, which means fewer tools, fewer examples, and more time spent debugging alone. Choose it when something outside search requires it; otherwise there is no reason to.

What to actually do

New site, or a template rebuild: JSON-LD, generated server-side from the same objects the template renders. Nothing else needs considering.

Existing Microdata that validates: leave it. Add JSON-LD only for entities the Microdata doesn't already cover, and don't duplicate.

Existing Microdata with recurring errors: replace it with JSON-LD rather than patching. Inline markup that has degraded through successive template edits is usually cheaper to rewrite than to repair — see common structured data errors for what those failures typically look like.

Mixed markup on the same entity: consolidate. Two sources describing one product invite contradiction, and Google's behaviour when sources disagree is not something you want to depend on.

The JSON-LD Markup Generator builds valid blocks for the common types entirely in your browser, and the Structured Data & JSON-LD Validator will confirm the output parses before it reaches a template. For type-specific requirements, the product schema field guide and FAQ schema guide cover the two types where format choice most often comes up.

Conclusion

The format debate has a clear default and a nuanced edge. JSON-LD is what Google recommends, what modern stacks generate most naturally, and what you should reach for on anything new. Microdata is not broken, not deprecated, and not worth migrating away from purely on principle. RDFa is a reasonable choice only when something beyond search requires it.

The decision that actually affects results is not which syntax you pick — it is whether the markup accurately and completely describes what is on the page. Get that right in any of the three and search engines will read it fine.