JSON-LD vs Microdata vs RDFa: Which Structured Data Format Wins?
Schema.org vocabulary (the types and properties that power rich results) can be written in three syntaxes: JSON-LD, microdata, and RDFa. They express identical facts, Google parses all three, and yet the choice is no longer close. Here's the comparison, the reasons, and the honest edge cases.
The three formats, same fact
Say a page needs to state: "ExampleApp has a 4.7 rating from 89 reviews."
JSON-LD: a self-contained script block, separate from your visible HTML:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "ExampleApp",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"reviewCount": "89"
}
}
</script>Microdata: attributes woven into the visible markup:
<div itemscope itemtype="https://schema.org/SoftwareApplication">
<span itemprop="name">ExampleApp</span>
<div itemprop="aggregateRating" itemscope
itemtype="https://schema.org/AggregateRating">
<span itemprop="ratingValue">4.7</span> from
<span itemprop="reviewCount">89</span> reviews
</div>
</div>RDFa: similar interleaving, W3C lineage, different attribute names (vocab, typeof, property).
Why JSON-LD won
1. Google recommends it. Google's structured data documentation has named JSON-LD the recommended format for years, and new rich result features are documented JSON-LD-first. When the dominant consumer of your markup states a preference, the debate is mostly over.
2. Separation of concerns. Microdata and RDFa entangle data with presentation: redesign a component, and it's easy to delete a <span> carrying itemprop="ratingValue" without noticing. JSON-LD lives in one block that survives any CSS or component refactor. In practice this is the big one. Most broken microdata in the wild broke during a redesign nobody connected to SEO.
3. Generated data fits naturally. Modern sites render from application state. Serializing an object to JSON-LD is one line in any framework; threading attributes through component templates is invasive and brittle. (This site, for instance, generates its review and rating JSON-LD from the same API data that renders the visible page, which is the pattern we'd recommend to anyone.)
4. Graphs are expressible. Multiple entities and their relationships (an app, its reviews, its publisher, breadcrumbs) sit comfortably in one JSON-LD block or several. Expressing cross-entity relationships in scattered HTML attributes gets miserable fast.
5. Debuggability. You can read a JSON-LD block top to bottom and validate it by pasting into a checker. Auditing microdata means reading the entire template with attributes in mind.
The honest case for the older formats
- Visible-content coupling. Because microdata annotates the actual rendered elements, markup-vs-page drift is structurally harder; with JSON-LD you must maintain the sync discipline yourself (Google requires markup to reflect visible content).
- Installed base. Enormous amounts of microdata ship inside older e-commerce themes and plugins, and it still works. If a legacy platform emits valid microdata, ripping it out for aesthetics is not a priority.
- RDFa's niche. RDFa remains relevant in semantic-web, government, and library contexts (often with vocabularies beyond schema.org). For commercial SEO, it's effectively a historical footnote.
One genuine warning: don't mix formats for the same entity. A theme emitting microdata ratings while you add JSON-LD ratings gives parsers two, possibly conflicting, statements, a classic source of rich-result flakiness. Pick one (JSON-LD), and suppress the other. If you're unsure whether your stack already emits markup, run any key page through the Rich Results Test before adding anything. Duplicated entities are far more common than people expect, especially on sites built with themes or page builders.
Migrating from microdata to JSON-LD without breaking anything
If you're sitting on a legacy microdata implementation and want to modernize, the order of operations matters:
- Inventory what's emitting markup. Themes, SEO plugins, and hand-rolled templates often overlap. Run the Rich Results Test on your key pages and note every detected entity and its source.
- Build the JSON-LD equivalents first. Generate them from your data layer, deploy them alongside the existing microdata, but on a staging URL; never run both formats for the same entity in production.
- Cut over page-type by page-type. Remove the microdata attributes and enable the JSON-LD block in the same deploy, starting with your least-trafficked template. Validate immediately after each cutover.
- Watch Search Console for two to four weeks per template. The valid-items count in the review-snippets report should dip briefly (re-crawl lag) and recover. A sustained drop means the new markup is missing a property the old one had, so diff them field by field.
- Delete the old code paths. Half-removed microdata that reappears with a theme update is the classic regression; make the removal real.
Expect the whole migration to be days of work, not weeks, and the payoff is that the next redesign won't silently destroy your stars.
One edge case worth flagging: some e-commerce platforms and page builders regenerate their built-in microdata on every theme update, so "removed" markup can quietly return. If you can't fully control the theme's output, check for a platform setting that disables built-in structured data (most major platforms added one precisely because of this conflict) and re-run the Rich Results Test after platform updates as well as after your own deploys.
Recommendation
For anything new in 2026: JSON-LD, no caveats. Generate it from live data rather than hardcoding it, keep it in sync with visible content, and validate with the Rich Results Test after every markup-adjacent deploy.
If your goal is specifically review stars, format is the easy 10%; eligibility rules (notably the self-serving restriction) are the 90% that decides whether stars render. Start with review schema markup: how to get star ratings in Google, then the hands-on AggregateRating walkthrough, or the full pillar guide: review schema and structured data. And if you'd rather outsource the whole layer, TheWebRatings publishes verified reviews with maintained JSON-LD on an independent page, free to start.
Frequently asked questions
JSON-LD, explicitly, and new rich result features are documented JSON-LD-first. Google still parses microdata and RDFa, but if you're writing anything new there's no reason to choose them.
Yes. Valid microdata is still parsed and can still earn rich results, which is why ripping out a working legacy implementation isn't urgent. The risk is maintenance: microdata lives inside your visible HTML, so redesigns silently break it far more often than JSON-LD.
For different entities, yes. For the same entity, no. Two markup blocks making conflicting statements about the same thing is a classic source of rich-result flakiness. If your theme emits microdata for something you also mark up in JSON-LD, suppress one of them.
Not meaningfully. A JSON-LD block is a few hundred bytes to a few kilobytes of inert script that browsers don't execute, and it doesn't block rendering. The performance cost rounds to zero next to a single image.
Inventory everything currently emitting markup, build the JSON-LD equivalents from your data layer, then cut over template by template, removing the microdata and enabling the JSON-LD in the same deploy. Validate each cutover and watch Search Console for a couple of weeks per template.