Schema Validator
Paste a JSON-LD schema block and check it for structural issues and missing required fields.
About the Schema Validator
Paste in a JSON-LD block and the validator first confirms @context and @type are present, then runs type-specific checks for Article, Product, FAQPage, and LocalBusiness against the fields each one commonly needs. It catches structural mistakes before publishing, though for full compliance it's still worth running the markup through Google's own Rich Results Test as well.
JSON is stricter than it looks
The single most common failure caught here is a trailing comma, a comma left after the last item in an object or array, which is tolerated by JavaScript object literals but is a hard syntax error in JSON proper. Structured data is copy-pasted and hand-edited constantly, a field added or removed at the end of a block without noticing the comma before it is left dangling or missing, this validator's JSON.parse step catches that instantly rather than leaving it to surface as a silent failure once the markup is live.
Type-specific checks only exist for four types
Article, Product, FAQPage, and LocalBusiness get their required fields checked individually, since these are among the most commonly used schema types across ordinary sites. Any other valid schema.org type, Recipe, Event, Organization, and dozens more, still gets the basic @context and @type checks but no field-by-field validation beyond that, flagged as a type this tool doesn't have specific rules for rather than silently skipped. Schema.org defines hundreds of types in total, building field rules for every one of them is a different, much larger project than what this tool sets out to do.
Structurally valid isn't the same as rich-result eligible
Passing every check here confirms the JSON-LD is syntactically correct and includes the fields this validator knows to look for, it doesn't confirm Google will actually grant a rich result for it. Google's own structured data guidelines specify required versus recommended properties per type, sometimes more demanding than a generic schema.org validity check, and enforce content-matching rules, the markup has to accurately reflect content that's genuinely visible on the page, not just present in the JSON-LD. Running markup through Google's Rich Results Test after it passes here is the way to check specifically against Google's own eligibility rules rather than general schema.org correctness.
Multiple schema blocks on one page
Pasting a JSON array instead of a single object is supported and checked as a batch, each object gets its own set of results labeled by position, useful for a page that legitimately carries more than one schema type at once, a BreadcrumbList alongside an Article, for instance, both can be validated together in a single pass instead of checking each block separately.
Pasting a full script tag works, not just raw JSON
This validator accepts the complete <script type="application/ld+json">...</script> block copied directly out of a page's source, it detects the wrapping tag and extracts the JSON automatically, rather than requiring the script tags to be stripped out by hand first. That matters in practice, the fastest way to check markup already live on a page is opening the page's view-source, copying the entire script element, and pasting it in unchanged, skipping the step of manually trimming it down to just the JSON portion.
Presence checks, not deep validation
The field checks here confirm a required key exists and isn't empty, they don't validate that the value itself is correctly formatted, a datePublished field containing plain text instead of a real ISO 8601 date still passes the presence check even though it would likely fail a stricter parser or a real rich-results eligibility check downstream. This tool is a fast first-pass filter for catching missing structure and outright syntax errors, not a substitute for testing the exact value formatting each field expects.
Frequently Asked Questions
What's the most common reason JSON-LD fails to parse?
A trailing comma after the last item in an object or array is the most frequent cause. It's allowed in JavaScript object literals but is a hard error in strict JSON, easy to leave behind after adding or removing a field near the end of a block.
Does this validator check every schema.org type?
No, only Article, Product, FAQPage, and LocalBusiness get field-specific checks. Other valid types still get basic @context and @type validation, but not detailed field requirements, since schema.org defines hundreds of types in total.
If my markup passes here, will Google definitely show a rich result?
Not necessarily. Passing confirms the JSON-LD is syntactically valid and includes the fields this tool checks for, but Google's own structured data guidelines have separate, sometimes stricter requirements, including that the markup accurately reflects content visible on the page. Google's Rich Results Test checks specifically against Google's own eligibility rules.
Can I validate multiple schema blocks at once?
Yes. Pasting a JSON array validates each object in it separately, with results labeled by position, useful for a page that carries more than one schema type at the same time, like a BreadcrumbList alongside an Article.
Do I need to strip out the script tags before pasting?
No. Pasting the complete script type="application/ld+json" block copied straight from a page's view-source works, the validator detects and extracts the JSON automatically, no need to manually trim the wrapping tags first.
Does a passing field check mean the value format is correct?
Not fully. Field checks confirm a required key is present and non-empty, they don't validate the value's exact format, a datePublished field containing plain text instead of a real date still passes the presence check. This tool catches missing structure and syntax errors, not every formatting requirement a field might have.