JSON-LD Validator
Paste JSON-LD — or a full HTML page, and every <script type="application/ld+json"> block is checked — to see syntax errors, missing required properties, missing properties Google recommends, and properties the type does not define. Rules follow Google's structured-data documentation. Runs entirely in your browser.
About this tool
Paste a JSON-LD block, or a whole HTML page, and the tool checks it as you type. From an HTML page it pulls every <script type="application/ld+json"> block and checks each one; a bare JSON payload is checked directly, including the nodes inside an @graph array. For each node it reports four things: JSON syntax errors, missing required properties (without which the markup is not valid for the type), missing properties Google's documentation marks required or recommended for the rich result, and properties that the type does not define. The rules cover the six types the companion generator supports — Article, FAQPage, BreadcrumbList, Organization, LocalBusiness and Product — and follow Google's structured-data reference. Everything runs in your browser; nothing is uploaded.
When to use it
Questions
What does "valid" mean here, versus Google's Rich Results Test or the schema.org validator?
Three different lenses. This tool checks that the JSON parses, that the properties required for the type are present, and that the properties Google's docs call for are there — offline, for the six types it knows. Google's Rich Results Test (search.google.com/test/rich-results) runs Google's own parser against the live or pasted markup and tells you whether the page is eligible for a specific search feature right now. The schema.org validator (validator.schema.org) checks the markup against the full vocabulary — every type and property schema.org defines — without any Google-feature opinion. Use this tool for a fast local check, the Rich Results Test as the final word on eligibility, and the schema.org validator when you use a type this tool does not cover.
What is the difference between a required and a recommended property?
A required property is one the type cannot be without: an Article needs a headline, a Product needs a name. Omit it and the markup is not valid for that type, and this tool reports it as an error. A recommended property is one Google's documentation says makes the rich result better or more complete — an Article's image and datePublished, a Product's image and brand — but leaving it out does not invalidate the markup. This tool lists those as warnings, not errors. Fix every error; treat the warnings as a checklist to work through where the data exists.
Why are properties the type doesn't define only shown as info, not errors?
schema.org is deliberately permissive: a node can carry any property, and consumers ignore the ones they do not understand. An unexpected property is far more often a harmless extra — a custom field, a property from a broader parent type, a typo you will spot — than a real problem, so flagging it as an error would cry wolf. The tool surfaces it as information so you can check whether you meant `datePublished` and wrote `publishDate`, without treating a deliberate extension as a failure.
Can extra properties hurt my rich result?
Not directly. Google reads the properties it needs and ignores the rest, so an unknown or surplus property will not disqualify the page. The reason to keep the block clean anyway is human: every stray property is something a future editor has to understand, and a misspelled property name that you meant to be a real one is invisible until you notice the rich result never appeared. Remove what you do not need, and make sure what remains is spelled the way schema.org spells it.
Does it handle @graph and multiple blocks on one page?
Yes. When the payload is an object with an @graph array, each node in the array is checked separately. When you paste an HTML page, every <script type="application/ld+json"> element is found and each one is checked — so a page with an Article block and a separate BreadcrumbList block gives you two sets of results. Each node is reported under its own @type heading so you can see which block a message belongs to.
My @type is an array like ["WebPage", "FAQPage"] — is that allowed?
Yes, a node can declare more than one type, and schema.org and Google both accept the array form. This tool resolves the array by taking the first type it recognises and checking the node against that type's rules. So ["WebPage", "FAQPage"] is checked as an FAQPage, because FAQPage is the type it has rules for. If none of the types in the array is one of the six it knows, it tells you the type is unrecognised rather than guessing.
If everything passes here, will I definitely get a rich result?
No — and no tool that checks markup alone can promise that. Valid structured data makes a page eligible; whether Google actually shows the enhanced listing depends on site quality, whether the markup matches what a visitor sees, whether the feature exists for your type and region, and Google's per-query judgement. A green result here means the markup is not what is holding you back. Confirm eligibility with the Rich Results Test, then give Google time to recrawl.
Why does it matter that the values match the visible page?
Google's structured-data policies require the marked-up content to be present and visible to the user. A price in your Product markup that differs from the price on the page, review stars with no reviews shown, FAQ answers that do not appear in the body — each is a policy violation that can trigger a manual action removing rich results across the whole site. This tool checks the shape of your JSON-LD; it cannot see your page, so keeping the values honest and in sync with what renders is on you.