JSON-LD vs Microdata
JSON-LD and Microdata are two markup syntaxes for expressing the same Schema.org vocabulary, one as a self-contained script block and the other as attributes woven into your visible HTML.
JSON-LD and Microdata are two markup syntaxes for expressing the same Schema.org vocabulary, one as a self-contained script block and the other as attributes woven into your visible HTML. They are formats, not features. Neither adds meaning the other cannot express, and choosing between them does not change what your page becomes eligible for.
Why the format you choose matters
Structured data is how you hand a machine an unambiguous version of what a page says. The syntax decides how well that description survives your CMS, your template edits, and whoever ships the next redesign.
The usual failure is not a wrong format. It is drift. Microdata sits inside the markup your designers move around, so a template change can strip half the properties without anyone noticing. JSON-LD sits apart from the rendered page, so it can keep declaring a price that changed three months ago. Both failures look identical from Google’s side: a page describing itself inaccurately. None of that rescues weak copy either. If the page underneath is thin, the honest first move is to fix what the page actually says, because markup describes content and cannot invent it.
How each format is parsed
- Both express one vocabulary. Schema.org defines the types and properties. JSON-LD and Microdata are only two ways of writing the same statements down.
- JSON-LD lives in its own block. A single script element with the type application/ld+json, placed in the head or body. Your visible HTML is untouched.
- Microdata annotates existing elements. The itemscope, itemtype and itemprop attributes attach to tags you already render, so data and display share one set of elements.
- Google reads both. Its structured data documentation lists JSON-LD, Microdata and RDFa as supported formats, and states a preference for JSON-LD.
- Validation is format-agnostic. The Rich Results Test and the Schema Markup Validator accept either syntax and report the same property-level errors.
- Rendering decides visibility. Markup injected by JavaScript is only present once the page is rendered, which applies to a JSON-LD block written by a tag manager just as much as to attributes added client-side.
After parsing, the syntax is gone. Google extracts a set of typed statements about the page and works from those, so two pages carrying identical properties in different formats arrive at the same place. What survives is the type you declared, the properties you filled, and whether they agree with the content a user sees. Google’s structured data guidelines are explicit that marked-up content should represent the main content of the page.
Format is the wrapper. The substance is whether you picked the correct type and filled its required properties, which is what the markup actually declares about a page. A perfectly formed JSON-LD block describing the wrong entity is worth less than clumsy Microdata describing the right one.
Where they differ in practice
| Dimension | JSON-LD | Microdata |
|---|---|---|
| Where it lives | A separate script block | Attributes on rendered HTML |
| Typical break | The block is duplicated or goes stale | A template edit removes a wrapping element |
| Editing cost | One place, one block | Every affected element |
| Tag manager injection | Practical and common | Rarely workable |
| Sync with visible content | Manual discipline required | Bound to the element it annotates |
| Google support | Supported, and the documented preference | Supported |
The blunt version
Google recommends JSON-LD in its own documentation. Google also parses Microdata, and has done for years. Both facts are true at once, and the second is the one that quietly disappears from migration proposals.
Run the arithmetic. If your Microdata validates and its properties are complete, converting it to JSON-LD buys you identical eligibility for developer hours you already paid once. Recommended is not required. A format swap on working markup is billable work with no measurable upside, and it is attractive to sell precisely because it is easy to scope, easy to demonstrate as a before-and-after diff, and almost impossible to be blamed for. Filling in missing properties is harder, slower and far less photogenic.
Migrate when there is a reason: your Microdata is genuinely broken, you need markup deployed without touching templates, the people maintaining it cannot edit templates, or you are rebuilding those pages anyway. Otherwise leave it. Watch what the migration is sold as, too. As of May 7, 2026, FAQ rich results are no longer appearing in Google Search, so no syntax will bring them back. Keeping FAQPage markup is still worthwhile for machine parsing, which is a question of how the answers are written rather than which format wraps them.
Example
Say a supplier with 900 product pages inherited Microdata written into its templates years ago. Spot checks return a valid Product type on every page, with name, image and brand present. An agency proposes a full JSON-LD rebuild, framed as bringing the site into line with Google’s recommendation. Nothing in the proposal names a missing property, a wrong type, or a single validator error. Meanwhile 300 of those products carry no price or availability data at all, because those fields were never mapped from the database. The rebuild would run for weeks and finish exactly where it started. Mapping the two missing properties into the existing Microdata takes a fraction of the time, and it is the only change that alters what the pages declare.
FAQ
Does JSON-LD perform better than Microdata in Google?
No. Google parses both formats and evaluates the same properties from either. The documented preference for JSON-LD is about maintainability, not scoring. If your Microdata validates and its properties are complete, changing syntax alters nothing about how the page is understood or what it qualifies for.
Can both formats run on the same page?
They can, and the usual result is two entities where you meant one. Google reads whatever it finds, so overlapping Product or Article blocks describing the same thing create ambiguity you did not intend. During a migration, either keep the two describing different entities or keep every shared value identical.
Which format should a new site start with?
JSON-LD, in almost every case. On a build with no legacy markup there is no conversion cost, and a single editable block is cheaper to maintain than attributes scattered through templates. The reasoning is operational. It has nothing to do with one syntax being read more favourably than the other.
Related terms
- Structured data — the vocabulary both syntaxes are competing to express.
- Unlinked brand mention — entity recognition without markup or a link involved at all.
- Sitewide link — another thing template-level code repeats across every page you publish.
If your Microdata validates, a JSON-LD migration is a preference upgrade, not a fix. Ask which property is currently wrong before you approve the invoice.