JSON-LD vs Microdata: Which Structured Data Format Should You Use?

Schema.org markup can be written in three syntaxes: JSON-LD, Microdata and RDFa. They describe the same vocabulary, Google reads all three, and yet the choice has real consequences for maintenance, correctness and the tools you can use. Here is the practical comparison.

The three formats in one example

A minimal Organization in each syntax. In JSON-LD the markup is a separate script, independent of the visible HTML:

<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "Organization", "name": "ACME", "url": "https://acme.example/" }
</script>

In Microdata the markup is attributes on the visible elements themselves:

<div itemscope itemtype="https://schema.org/Organization">
  <a itemprop="url" href="https://acme.example/"><span itemprop="name">ACME</span></a>
</div>

RDFa is similar to Microdata with different attribute names (vocab, typeof, property). It is rare on modern sites and we will leave it aside.

What Google says

Google’s documentation recommends JSON-LD, and new features are usually documented with JSON-LD examples first. Microdata and RDFa remain fully supported for all rich result types; there is no ranking or eligibility difference. The recommendation is about ease of implementation, not about results.

Why JSON-LD usually wins

It is decoupled from the layout. A redesign cannot accidentally drop an itemprop from a heading. The markup is generated from data, not from the DOM structure.
It can describe things that are not on the page in the same shape. Nested entities, @graph, @id references between blocks: all of this is awkward or impossible in Microdata.
It is easy to generate and test. It is just JSON: serialize an object, assert on it in a unit test, validate it in CI.
It is easy to inject from a CMS plugin without touching templates, which is why most SEO plugins use it.

Where Microdata still makes sense

The site already has it and it works. Rewriting correct Microdata to JSON-LD gains nothing in search. Spend the effort on pages that have no markup.
You want the markup to be guaranteed to match the visible content. Because Microdata annotates the real elements, the price in the markup is the price the user sees. With JSON-LD, keeping the two in sync is your job.
Email markup and some other consumers historically preferred Microdata. This is niche.

The mixed-format trap

The one thing to avoid is both formats describing the same entity on one page with different values: Microdata in the theme says the product costs 19.99, the plugin’s JSON-LD says 24.99. Google may pick either, and validators report duplicate entities. If you migrate, remove the old format in the same release.

Mixed formats describing different things are fine: breadcrumbs in Microdata from the theme and a Product in JSON-LD from the shop plugin coexist without conflict.

Checking either format

Whichever syntax you use, validate against three layers: syntax, the schema.org vocabulary, and Google’s per-type requirements. The Schema Markup Checker extracts both JSON-LD and Microdata from a page, reports them side by side, and for Microdata the Chrome extension highlights the annotated elements on the page itself, which is the fastest way to see which itemprop a template forgot.

Recommendation

For new work, use JSON-LD, rendered on the server, generated from the same data that renders the page. For existing Microdata that validates cleanly, leave it alone, and never run both formats on the same entity. Then put a site scan on a schedule so the next redesign does not quietly break what you built.