Home › Tools › JSON-LD Validator
JSON-LD Validator
Validate JSON-LD in your browser: syntax errors with line numbers, missing @context or @type, and missing required fields for common types.
SerpPrism's JSON-LD Validator is a free online tool that checks pasted JSON-LD the way a developer needs it checked: is the JSON syntactically valid (and if not, exactly where it breaks), does every node carry @context and @type, and are the fields Google actually requires for common types — Article, Product, FAQPage, HowTo, Recipe and more — present. There is no sign-up and nothing is uploaded; validation runs in your browser. It is built for the moment before you ship a template change, when a missing comma or a forgotten property is still a thirty-second fix. Paste a block, with or without the surrounding script tag, and get errors, warnings, and a list of the types found. If you need to write markup from scratch instead, the Schema Markup Generator builds the common types field by field.
How to use it
- Copy the JSON-LD — just the JSON, or the whole script tag; the tag is stripped for you.
- Paste it in. Syntax is checked first, then structure: @context, @type, and the required fields for every type found.
- Fix errors top-down. A syntax error masks everything below it, so re-paste after each fix until only warnings — or nothing — remain.
What 'valid' means, in three layers
A JSON-LD block can pass one layer and fail the next. Layer one is JSON syntax: the text parses at all. Layer two is JSON-LD structure: a @context that says the vocabulary is schema.org, and a @type on every node that says what each thing is. Layer three is search-engine requirements: Google asks for specific properties per rich result type, and a Product without offers is valid JSON-LD that earns nothing.
Most validation failures people chase are layer-one problems wearing layer-three clothes — the rich results report says the markup is unusable, and the actual cause is a trailing comma eleven lines up. This validator checks all three layers in order and labels which one each finding belongs to, so you fix the comma before you rewrite the schema.
Why the line number matters
JSON's own error reporting is a character position, which in a pasted block of two hundred lines is nearly useless. This tool converts the position into a line and column, because the actual suspects are always local: a trailing comma after the last property, an unquoted key, a string closed with the wrong quote, or a bracket closed one line too early.
Fix only the first syntax error, then check again. Parsers stop at the first break, so everything after it is unexamined — what looks like one error is sometimes three, revealed one at a time. That is normal, and it is why the loop is paste, fix, re-paste.
What this tool deliberately does not do
It does not fetch a URL and extract the markup for you. Reading another site's page from your browser is blocked by cross-origin rules, and routing it through a proxy would mean this site sees every URL you check — the same trade every tool on this site refuses to make. Paste the block; it takes ten seconds.
It also cannot promise rich results. Eligibility depends on the markup matching the visible page content, on the page itself being indexed, and on Google's own quality calls, none of which a validator can see. And its field-level checks cover the common types listed in the questions below — for any other schema.org type it checks structure only, and says so, rather than pretending to a completeness it does not have.
Questions
Is my JSON-LD uploaded anywhere?
No. Parsing and checking happen as JavaScript in your browser. Nothing you paste is sent to a server or stored.
What is the difference between an error and a warning here?
An error means the block will not work: it does not parse, it is missing @context or @type, or a type is missing a field Google requires. A warning means a recommended field is absent — the markup still works, but a rich result may lose features or not appear.
Can I paste the whole script tag?
Yes. If the pasted text contains a script tag with type application/ld+json, the tag is stripped and only the JSON inside is validated.
Why does Google call my valid JSON-LD ineligible?
Usually because the markup describes things the page does not visibly contain — reviews for a product the page never shows, or an event that is not on the page. Markup must reflect page content; a validator can check the fields, but only you can check the honesty.
Does every node need its own @context?
No. @context belongs on the root object, and nodes inside an @graph inherit it. This validator only demands @context at the root — nodes in a graph are checked for @type and fields, not for repeating the context.
Which types get field-level checks?
Article, NewsArticle and BlogPosting; Product; FAQPage; HowTo; Recipe; Event; Organization; WebSite; BreadcrumbList; VideoObject; ItemList; LocalBusiness; and Person. Any other type gets syntax and structure checks, with a note saying field checks do not cover it.