Overview
Introduction
JSON-LD structured data is what turns a plain search result into a rich one: star ratings under a product listing, an FAQ dropdown under a blog post, a breadcrumb trail instead of a raw URL. It's also silent when it's broken - a missing required field or a typo in a property name doesn't throw a browser error, it just means the rich result never shows up, and there's no obvious signal telling you why.
This tool parses JSON-LD, whether pasted directly or extracted from a full page's HTML, and checks it against the property requirements search engines actually document for common types, so you can catch a missing `datePublished` or `author` before it costs you a rich result rather than after.
What Is Structured Data Validator?
A client-side JSON-LD validator that extracts every structured data block from a page (or accepts bare JSON-LD directly), parses it, identifies its @type, and checks for the required and recommended properties documented for the most common schema.org types.
It's not a full schema.org type-system validator - it doesn't know every one of the hundreds of types schema.org defines - but it covers the handful (Article, Product, FAQPage, Organization, LocalBusiness, Review, BreadcrumbList) that account for the large majority of structured data actually deployed on the web.
How Structured Data Validator Works
The input is first tried as raw JSON via JSON.parse, which handles the common case of pasting just the JSON-LD object itself. If that fails, the input is parsed as HTML and every <script type="application/ld+json"> block is extracted and parsed individually, so a page with multiple structured data blocks gets each one checked separately.
Each parsed value is flattened into a list of nodes - handling a bare object, an array of objects, or an object with an @graph array identically - then each node's @type is read and checked against a hardcoded required/recommended property table for that type, or reported as parsed-but-unchecked if the type isn't in the table.
When To Use Structured Data Validator
Right after writing or editing JSON-LD by hand, to catch a missing required field before it ships - a typo'd property name silently does nothing, and this surfaces that immediately.
While auditing an existing site for structured data gaps, since it's common to find a Product schema missing an offers block, or an Article missing datePublished, months after the markup was first added.
Often used alongside Article Schema Generator, Product Schema Generator and FAQ Schema Generator.
Features
Advantages
- Checks against the specific required/recommended properties documented for each type, not just generic JSON syntax validity.
- Works on bare JSON-LD or a full HTML page interchangeably, so you can paste exactly what you have without reformatting it first.
- Runs entirely in the browser - nothing is sent to a server, which matters when the markup contains draft content or unpublished pricing.
- Handles all three common JSON-LD shapes (single object, array, @graph) instead of assuming only one.
Limitations
- Only checks property presence, not value correctness - a `datePublished` field containing the wrong date, or an `author` field pointing to the wrong person, will still pass the check.
- The required/recommended table only covers seven common types; anything else is reported as syntactically valid without a fields check.
- A live fetch only works when the target site sends permissive CORS headers, which most ordinary websites don't; use the paste fallback for anything else.
Examples
Best Practices & Notes
Best Practices
- Validate JSON-LD immediately after writing it, not after it's already deployed - a missing field is a one-line fix while you're still looking at the code, and a much longer investigation once it's live and you're wondering why a rich result never appeared.
- Treat "missing recommended" differently from "missing required": required fields typically block eligibility for a rich result entirely, while recommended fields usually just mean a plainer version of the result shows.
- Re-run this check whenever a CMS template that generates JSON-LD changes, since a template bug can silently drop a field across every page that uses it.
- Cross-check anything this tool doesn't recognize (an unlisted @type) against Google's own Rich Results Test before assuming it's fine.
Developer Notes
The required/recommended tables intentionally mirror Google Search Central's documented fields rather than the (often looser) bare schema.org spec, since Google's rich-result eligibility is the practical reason most sites add structured data at all. FAQPage and BreadcrumbList get bespoke array-shaped validators since their requirements are nested (mainEntity[].acceptedAnswer.text, itemListElement[].position/name/item) rather than flat top-level properties.
Structured Data Validator Use Cases
- Checking hand-written or LLM-generated JSON-LD for missing fields before pasting it into a page's <head>
- Auditing an existing site's structured data for gaps that might explain a missing rich result
- Verifying a CMS plugin's auto-generated schema markup actually includes the fields the plugin claims to add
- Spot-checking JSON-LD extracted from a competitor's page to understand what fields they're populating
Common Mistakes
- Adding a Product schema with only a name and price, and no image or description, which technically parses fine but rarely earns a rich result in practice.
- Nesting acceptedAnswer as a plain string instead of an object with an @type and text property in FAQPage markup, which fails silently.
- Forgetting that itemListElement in a BreadcrumbList needs position, name, and item on every entry, not just the last one.
Tips
- If a block reports "invalid JSON", check for a trailing comma or an unescaped quote inside a string value first - those are the two most common hand-editing mistakes.
- Run the page's rendered HTML (View Page Source, not your CMS editor view) through this tool, since some templates inject or strip JSON-LD at render time.