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

The short answer: use JSON-LD for almost every site. It is the format Google recommends, it lives in one separate script block, and you can add, edit, or remove it without touching your visible page. Microdata and RDFa describe exactly the same schema.org data and Google still reads both — so keep them only where they are already embedded in your templates and working, or where your platform gives you no other way to add markup. Never describe the same entity in two formats at once. The rest of this post shows you the same entity in all three formats, so the trade-off is concrete rather than theoretical, and gives you a migration checklist if you decide to switch.

What the three formats actually are

All three formats are just ways of attaching schema.org vocabulary — types like Product, Article, and Organization, and properties like name, price, and author — to a page. The vocabulary is the same; only the delivery mechanism differs. Google's structured-data introduction states that all three formats are equally fine for Google as long as the markup is valid, and that JSON-LD is the recommended format in most cases because it is easiest to implement and maintain. Schema.org's own getting-started guide shows the same idea from the other side: it teaches the vocabulary with Microdata first, then notes that most examples on the site are also shown in RDFa and JSON-LD.

The practical difference in that table is the editing risk. With JSON-LD, the markup and the page are two separate things: a designer can redesign the page without ever seeing the schema, and an SEO can rewrite the schema without ever touching the design. With Microdata and RDFa, the markup is woven into the page itself, so every template change is also a schema change — and a schema break that nobody notices, because the page still looks fine.

The same entity, three ways

Here is one simple entity — a product with a name and a price — expressed in each format. The data is identical in all three; only the syntax changes.

JSON-LD — one block, separate from the content:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Pour-Over Coffee Kit",
  "offers": {
    "@type": "Offer",
    "price": "49.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Microdata — attributes on the visible HTML:

<div itemscope itemtype="https://schema.org/Product">
  <h2 itemprop="name">Pour-Over Coffee Kit</h2>
  <div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
    <span itemprop="price">49.00</span>
    <meta itemprop="priceCurrency" content="USD" />
    <link itemprop="availability" href="https://schema.org/InStock" />
  </div>
</div>

RDFa — attributes, with an explicit vocabulary declaration:

<div vocab="https://schema.org/" typeof="Product">
  <h2 property="name">Pour-Over Coffee Kit</h2>
  <div property="offers" typeof="Offer">
    <span property="price">49.00</span>
    <meta property="priceCurrency" content="USD" />
    <link property="availability" href="https://schema.org/InStock" />
  </div>
</div>

Read the three examples as a maintenance question, not a syntax quiz. In the JSON-LD version, changing the price means editing one line in one block. In the other two, changing the price means finding the right element in the template, and if that template is shared across hundreds of product pages, every one of them carries the same risk. Nested data makes the gap wider: an Organization with an address, or a Product with several offers, nests cleanly inside a JSON-LD block but turns Microdata and RDFa templates into a tangle of nested scopes that is easy to break and hard to read.

When to use each format: the decision guide

• Use JSON-LD when: you are starting fresh, you use a CMS or plugin that can inject a script block, you manage many pages from templates, or you expect the design to change. This covers nearly every new project, which is why it is the default recommendation.
• Keep Microdata when: it is already live, valid, and earning rich results, and your templates rarely change. Rewriting working markup for its own sake buys nothing — the format itself does not change your ranking or your eligibility, only the validity of the data does.
• Keep RDFa when: the same applies — it is already embedded, valid, and stable — or when your platform or publishing toolchain already emits RDFa (some Drupal and publishing setups do) and replacing it would mean custom development for no user-visible gain.
• Do not use two formats for the same entity: describing one product in JSON-LD and again in Microdata gives search engines two descriptions of the same thing. If they ever disagree — and after a template edit, they often do — neither wins cleanly, and debugging means checking two places instead of one.
• Do not pick a format to chase a ranking boost: no format ranks better than another. Valid markup makes a page eligible for a rich result; the format is not a ranking factor. If someone sells you a format switch as an SEO win, the win is in fixing invalid data, not in the new syntax.

Migrating from Microdata or RDFa to JSON-LD: a checklist

If you decide the maintenance benefit is worth the switch, migrate in this order so you are never without valid markup:

1. Audit what you have. List every page type that carries Microdata or RDFa and every type and property it uses. The goal is a one-to-one map, not a redesign — the new block must say the same things the old attributes said.
2. Generate the JSON-LD, do not hand-type it. Use a free JSON-LD schema generator that runs in your browser to build each block from a form, then check the output for the same types and properties your audit found.
3. Validate before you publish. Run the block through a JSON formatter and validator to catch syntax errors, then test the live page with Google's structured-data testing tools — the Rich Results Test for Google eligibility and the Schema Markup Validator for vocabulary correctness.
4. Remove the old attributes only after the new block validates. Publish the JSON-LD first, confirm it is detected, then strip the Microdata or RDFa attributes in the same release cycle. Leaving both in place "just in case" is how duplicate descriptions happen.
5. Re-check a sample of each page type after launch. Template bugs break markup in bulk: one wrong variable can invalidate hundreds of pages at once. Search Console's enhancement reports will show the same error across a page type if one slipped through.

Choosing a JSON-LD schema generator tool

Most sites should not hand-write JSON-LD at all: JSON is strict, and one stray comma or curly quote silently invalidates the whole block. When you compare JSON-LD generator tools, check four things: that the output validates without editing, that it supports the schema types your pages actually use (not just a long list of types you will never need), that it lets you combine types in one block for pages that need more than one, and that it runs without forcing you to create an account or upload your content to a server. A generator that meets those four tests will produce the same block whether you are marking up one product page or a whole catalogue. Our complete guide to JSON-LD structured data covers which schema types are worth implementing in the first place, so you generate markup for the pages that benefit instead of marking up everything.

Common mistakes with all three formats

• Marking up content visitors cannot see. Every format has the same rule: markup must describe visible page content. Hidden prices, ratings, or offers are a quality violation in any syntax, and fabricated ratings can draw a manual action.
• Mixing formats for one entity. Pick one format per entity and stick to it. A page can carry JSON-LD for its Article and Microdata for an unrelated embedded item, but the same product described twice is a conflict waiting to happen.
• Copying a block without changing the values. A generator's example Organization, left unchanged on a real site, describes a business that does not exist. Every value in the block must be true of the page it sits on.
• Assuming valid means eligible. A block can be perfectly valid schema.org and still not qualify for a rich result, because each rich result type has its own required properties. Validation is step one; the Rich Results Test's eligibility check is step two.

FAQ

JSON-LD vs Microdata vs RDFa: which should I use?
JSON-LD, for almost every site. All three describe the same schema.org data and Google reads all three, but JSON-LD sits in one separate script block, so template changes cannot silently break it. Keep Microdata or RDFa only where they are already live, valid, and stable.

Does Google still support Microdata and RDFa?
Yes. Google's documentation lists all three formats as supported and says all three are equally fine as long as the markup is valid. Support is not the question — maintenance is. Google recommends the format that is easiest to implement and maintain, which in most cases is JSON-LD.

Can I use JSON-LD and Microdata on the same page?
You can, but not for the same entity. Different entities on one page may use different formats, but describing one product in both formats creates two descriptions that can disagree after an edit. Pick one format per entity.

Will switching to JSON-LD improve my rankings?
No — and neither will any other format switch on its own. Structured data is not a ranking factor; valid markup makes a page eligible for a rich result, which can raise click-through rate at the same position. If a switch helps, it helps because it fixed invalid or conflicting data, not because of the new syntax.

What is the best JSON-LD schema generator for a small site?
The best JSON-LD generator tools are the ones whose output validates without editing, that cover the schema types your pages actually use, and that run in the browser without an account. For a small site, a free browser-based generator is usually enough: fill in the form, validate the output, and paste one block per page. Avoid tools that lock common types behind a signup or that generate markup for content your pages do not actually show.

How do I convert Microdata to JSON-LD?
Audit the types and properties your Microdata uses, generate an equivalent JSON-LD block, validate it, publish it, confirm it is detected, and only then remove the old attributes. Never run both formats for the same entity in production, and re-check a sample of each page type after launch, since template bugs break markup in bulk.