Use JSON-LD for structured data in 2026. It is Google's explicitly recommended format, it is what AI systems parse most reliably, and it keeps your markup in one clean block separate from your visible HTML. Microdata and RDFa still work and are still understood, but there is almost no reason to choose them for new pages — and good reasons to migrate away from them. That is the short answer; here is why the three formats exist and when the older two still make sense.
The three formats, briefly
All three encode the same Schema.org vocabulary — the difference is only where and how the data lives in your page.
- JSON-LD puts structured data in a single <script type="application/ld+json"> block, usually in the head or end of body. It is completely decoupled from the visible markup, so you can add or edit it without touching your layout.
- Microdata annotates your existing HTML with attributes like itemscope, itemtype, and itemprop sprinkled across the visible elements.
- RDFa works like Microdata but uses a different attribute set (vocab, typeof, property) and comes from the broader semantic-web/linked-data world.
If you are new to any of this, start with our practical guide to JSON-LD and Schema.org, which shows the format in full.
Why JSON-LD wins for almost everyone
The decoupling is the whole argument. Because JSON-LD is a self-contained block, you can generate it server-side, inject it via a tag manager, template it, and validate it in isolation. When your markup and your visible content are tangled together — as they are with Microdata and RDFa — every design change risks breaking your structured data, and every structured-data fix risks breaking your layout.
JSON-LD is also the format Google's documentation recommends first for nearly every rich result type, and it is the easiest for AI systems and parsers to consume because it is just clean, predictable JSON. It handles complex, connected data gracefully too: you can link multiple entities with @id references, which is the basis of the pattern in our guide to Schema @graph and nesting.
When Microdata or RDFa still make sense
There are narrow cases. If you are on an old CMS or template you cannot easily add a script block to, but you can edit inline attributes, Microdata may be the path of least resistance. RDFa appears in enterprise and linked-data contexts where the same markup feeds internal semantic systems, not just search engines. And if a page already has working, validated Microdata that generates the rich results you want, there is no urgent need to rip it out — "if it validates and works, leave it" is a reasonable stance.
The one thing you should not do is mix formats for the same entity on the same page. Describing one product in both Microdata and JSON-LD invites conflicting or duplicated data and confuses parsers. Pick one format per entity.
Migrating and validating
If you are moving from Microdata or RDFa to JSON-LD, do it page-type by page-type, not all at once. Build the JSON-LD block, confirm it reproduces every property the old markup carried, then remove the inline attributes in the same deploy so you never run both simultaneously. Watch that no property silently drops during the swap — a missing price or rating can cost you a rich result. Then validate everything, because a format change is exactly when errors creep in; our structured data validation guide covers the testing tools and the errors they catch.
For nearly every site in 2026, the answer is simple: write new structured data as JSON-LD, keep it validated, and migrate old inline markup when you touch those templates anyway. To check what structured data your pages currently expose and whether it is parseable, run the CheckMy.site scanner and see your markup the way crawlers and AI do.