I get asked about this less often than the bigger strategic questions, but it's worth answering properly, because the choice actually affects how maintainable your entity architecture stays over time.
The Core Structural Difference
Microdata works by adding special attributes, itemscope, itemtype, itemprop, directly onto your existing HTML elements. The structured data is woven into the visible page markup itself, meaning every piece of schema is tied to a specific HTML element wrapping specific visible content.
JSON-LD works differently. It's a separate block of structured data, written in JSON format, sitting inside a script tag, completely detached from your page's visible HTML and content structure. The two don't have to align element-by-element the way microdata requires.
Why That Difference Actually Matters in Practice
Which signal is most important for AI search citation?
This isn't a purely academic distinction. Because JSON-LD is detached from the visible HTML, it can be added, edited, or removed without touching the page's actual content or design at all, a developer or a CMS plugin can inject or update a JSON-LD block independently of whatever a content editor or designer is doing to the visible page. Microdata requires structured data to be threaded directly through the visible markup, meaning a redesign or a content edit can accidentally break the schema attached to it, since the two are physically intertwined.
For a site with more than a handful of pages, or one that changes design or content regularly, this maintainability gap compounds significantly over time. I've audited sites with microdata that broke silently after a template redesign, nobody removed the schema deliberately, it just got orphaned when the HTML structure it depended on changed.
Why This Matters Even More for @graph Architecture Specifically
This connects directly to something I've written about elsewhere: proper entity-first schema uses @id cross-referencing to connect related entities into one coherent graph, an Organization linking to its Services, a Person linking to their published work. Building that kind of interconnected structure is significantly easier in JSON-LD, where you're working with a clean, centralized data structure, than in microdata, where the same relationships would need to be threaded through scattered, individually-tagged HTML elements across potentially many different pages. This is part of why the custom schema work I do is built exclusively in JSON-LD, not as a stylistic preference, but because the format genuinely supports the architecture better.
The actual markup difference
Does Google Actually Prefer One Over the Other
Google's own documentation explicitly recommends JSON-LD as the preferred format where possible, while still supporting microdata and RDFa as valid alternatives it will parse. That's not a minor detail, when the search engine you're building structured data for tells you which format it prefers, that's a strong, practical signal worth following rather than treating all three formats as functionally interchangeable choices.
When You Might Still Encounter Microdata
How has AI Overview affected your or clients' organic traffic quality?
Click to vote • Results shown after voting
You're most likely to run into microdata on older sites, or sites built on certain legacy CMS templates and plugins that generated it automatically years ago, before JSON-LD became the dominant standard. If I find existing microdata during a technical audit, the standard recommendation is migrating it to JSON-LD rather than trying to maintain or extend the older format, since layering new JSON-LD on top of legacy microdata risks creating conflicting or duplicate schema signals.