Skip to the tool
OnPageKit

Structured Data Validator

Check JSON-LD syntax, types and required fields in your browser.

nothing pasted yet

Start it with a brace and it is treated as one block. Paste a whole document and every application/ld+json script in it is pulled out and checked in order. Nothing is uploaded: the vocabulary ships with the page.

Required fields are always reported. Recommended ones are what Google asks for beyond the minimum — useful on a first pass, noise once you have decided which of them your data actually has.

Blocks
0
Parsed
0
Typed nodes
0
Missing
0
  • Nothing to check yet. Paste a JSON-LD block on its own, or the whole page source — every <script type="application/ld+json"> in it is pulled out and read in document order.

This checks syntax and schema.org conformance in your browser. Eligibility for a rich result is a separate judgement, made by Google against the crawled page, and the place to settle it is its Rich Results Test.

Everything runs in your browser. Nothing you type is sent to a server.

Found a bug in this tool? Report it.

Share this tool

What this structured data validator checks

Paste a JSON-LD block, or the entire source of a page, and this structured data validator reads it back to you: which blocks parse and which do not, where exactly a broken one breaks, every node that declares a @type, and which of the fields Google documents for that type are missing. It runs in your browser against a copy of the vocabulary shipped with the page, so it works on a staging site, on a draft nobody has published, and on markup you would rather not send anywhere.

Valid means three different things

The word does a lot of work, and most confusion about structured data comes from three questions being answered as if they were one.

Is it parsable JSON? A machine question with a yes or no answer. A trailing comma, a curly quote pasted from a document, a comment left behind by a template — any of these and the block is skipped in its entirety. Not the broken property: the whole block, silently.

Does it conform to schema.org? Are the types real, do the property names exist, and are the values the right shape — an absolute URL where a URL belongs, an ISO date where a date belongs, a plain number where a price belongs. This is where most markup that parses still fails to do anything.

Will Google show a rich result for it? A commercial judgement, not a technical one, and the only one this page cannot answer. Google decides it per URL, against the page as crawled, weighing things no validator sees: whether the marked-up content is genuinely visible to a visitor, whether the site has a history of accurate markup, whether the feature exists in your country. Its Rich Results Test is where that answer lives, and it needs a live address to give one.

Keep the three apart and the workflow is obvious. Fix syntax and conformance here, before publishing, as many times as it takes. Ask Google once, afterwards, about the page it can actually fetch.

The errors that come up again and again

A price written as a price. "price": "£3.50" fails because the property takes a number and the currency is declared separately in priceCurrency. The same goes for "1,299".

A date in the local format. 05/09/2026 is unreadable as data — it is two different days depending on which side of the Atlantic wrote it. Every date property wants ISO 8601.

A relative URL. "logo": "/logo.png" means nothing to a consumer that received the JSON without the page it came from. Image, logo, URL and sameAs all want the full address.

Markup describing something the page does not show. Review stars for reviews that appear nowhere on the page, an FAQ block whose questions are not in the visible text. This is the one category a syntax check cannot catch and the one that draws a manual action, because it is the difference between describing your page and inventing it.

A missing @context. Without it the property names have no vocabulary behind them, and the block is discarded before anything else is examined.

Where the requirements come from

The required and recommended fields are Google's documented lists for each type, not the full schema.org definition. The two are different by design: schema.org describes what can be said about a thing, and Google's documentation says what it needs in order to display a particular feature. Article has no required properties at all in Google's list, which surprises people and is correct — the article rich result depends on the page, not on the markup.

When you are producing the markup rather than checking it, the generators write blocks that pass this check by construction: Article, Product, FAQPage and LocalBusiness each have one.

Frequently asked questions

Does passing this check mean my page will get a rich result?

No, and nothing offline can promise that. Three separate questions hide inside the word valid, and this tool answers the first two: is the text parsable JSON, and does it use schema.org types and properties correctly. The third — will Google actually show a rich result for this URL — belongs to Google, is judged against the crawled page rather than a draft, and is answered at search.google.com/test/rich-results.

Why does my block parse in one validator and fail here?

Almost always a trailing comma, a smart quote pasted from a word processor, or a comment left in from a template. Some editors quietly repair these before showing you the file. This tool scans for the four ways hand-written JSON usually breaks and reports the line and column of the first one it finds, rather than passing along an engine message that varies by browser.

Should structured data go in JSON-LD, Microdata or RDFa?

JSON-LD, unless something outside your control forces otherwise. Google names it as the preferred syntax, it sits in one block rather than being threaded through the markup, and it survives a redesign because it is not attached to the elements that render. This validator reads JSON-LD only, for the same reason.

What is @graph for?

Grouping several entities that belong to one page into a single block, so they can refer to each other by @id instead of being repeated. A typical page has a WebSite, an Organization and an Article all describing the same publisher; with @graph the publisher is declared once. The tool walks into the array and checks each member on its own.

Is a type this tool does not recognise an error?

No. The vocabulary bundled here is a snapshot taken at build time, and schema.org publishes new types faster than any offline copy is refreshed. An unrecognised type is reported as a warning that means check the spelling first — the overwhelming majority of them turn out to be a capitalisation slip.

Related tools

Updated