JSON LD Validator: Schema.org and Google Rich Results

How to use the JSON LD Validator: Schema.org and Google Rich Results

1. Paste the markup or the pagePaste the JSON-LD alone, or the HTML of a page. If the text has script tags, the page reads each one of type application/ld+json and ignores the other scripts. Line numbers are those of what you pasted.
2. Fix the errors firstErrors are things a parser cannot read: invalid JSON, a type or property that is not in schema.org, or a missing context. Press the line button to jump to the place in your text. Names that look like typos come with the name that was probably meant.
3. Read the warningsWarnings are things that parse but are probably wrong: a property used on the wrong type, a date that is not ISO 8601, a relative URL, a number written with a currency symbol, or a value that is not one of the allowed ones. Notes are suggestions.
4. Check the rich resultsFor each type that Google supports, the page lists the properties that Google requires and that are missing, and the ones it recommends. Add the required ones first. The link beside each result opens Google's own page.

What JSON-LD is, and what makes it fail

JSON-LD stands for JSON for Linked Data. A block has a @context, which says which vocabulary the names belong to, and one or more nodes, each with a @type and properties. For structured data the context is schema.org, written as https://schema.org. A parser reads the block as data, not as text, so it cannot guess what you meant: a name that is not in the vocabulary is simply ignored, and invalid JSON makes the whole block unreadable.

That is why the checks come in layers. First the JSON must be valid. The page follows RFC 8259, and a trailing comma, a single quote, a comment, or a line break inside a string is an error with its line and column. Then the context has to name schema.org, with the https:// in front, because a context of schema.org alone is read as a relative address. Then the names and values are checked against the vocabulary.

The schema.org vocabulary

The page holds the current schema.org release: 939 types, 1,538 properties, and 546 members of enumerations. A type is accepted with or without the schema: prefix or the full address. A name that is not in the release is an error, and the page suggests the closest name, which is how Organizaton becomes Organization and datepublished becomes datePublished. The case matters, because JSON-LD names are case sensitive.

Each property is defined for certain types and expects certain kinds of value. When a property is used on a type that it is not defined for, such as servesCuisine on a Person, the page warns, because search engines usually ignore it, and it lists the types that do have it. A subtype may use all the properties of its parents, so a Restaurant may use everything that a LocalBusiness, an Organization, and a Thing may. Role types, which schema.org uses to attach details to a relationship, are left out of this check on purpose.

Values: dates, addresses, numbers, and enumerations

A date has to be written as ISO 8601: 2026-10-04, or with a time, 2026-10-04T09:30:00+02:00. A year or a year and a month are accepted too. An address that a parser has to fetch, such as the URL of an image, has to be absolute, because a relative address has no host to start from. A price or a rating has to be a number: 29.99, not $29.99 and not great, with the currency in its own property.

Some properties take a fixed set of values, called an enumeration. The availability of an offer is one of the ItemAvailability values, and the page accepts InStock, schema:InStock, and https://schema.org/InStock, and warns about InStok with the right name. A value taken from another vocabulary, such as the old GoodRelations addresses that appear in some examples, is accepted as it is. A property whose value is null is reported, because JSON-LD drops it.

What Google asks for

Valid schema.org is not the same as eligible for a rich result. Google asks for particular properties for each feature. The page holds the lists from Google Search Central for nine of them. A product snippet needs a name and at least one of a review, an aggregate rating, or an offer, and an offer needs a price. A recipe needs an image and a name. An event needs a name, a start date, and a location with an address. A job posting needs a title, a description, a posting date, a hiring organization, and a location. A video needs a name, a thumbnail, and an upload date. An article has no required properties at all, but Google recommends an author, the dates, a headline, and an image.

The page shows what is missing, which is the part that stops a rich result, and what is only recommended. It also says when a type is still valid but no longer shown. Google no longer shows FAQ rich results in Search and has removed the documentation for them, and it no longer shows how-to rich results. The markup is not wrong. It just has no effect on how a result looks.

Pasting a page

If the text has script tags, the page takes the ones whose type is application/ld+json, and ignores the others. A block may have an HTML comment around the JSON or a CDATA wrapper, and the page removes them before it reads the JSON. The line numbers of every message are the numbers in the text that you pasted, so the line button takes you to the right place.

How the checker was tested

The 211 JSON-LD examples in schema.org's own examples file were checked. They are written by the schema.org editors and cover products, events, recipes, people, organizations, and many more types, in their script tags. The page found no error in any of them. The only warnings were 30 web addresses that the examples write in short, such as janedoe.jpg without a host, which are what the page is meant to report.

To check that errors are found, one name in each example was changed to a typo: two letters swapped, a letter left out or added, or the wrong case, in a property or a type. The page reported every one of the more than 150 changes as an error, and named the original in at least 85% of them. A name that happens to be another real name cannot be known to be a mistake, and those were not counted. Dates, addresses, numbers, enumerations, and the Google requirements were tested on written examples.

Limits and accuracy

• The page checks the text that you paste. It does not fetch a URL, so it cannot see markup that a script adds to a page after it loads, and it does not check that the markup matches what is visible on the page, which Google requires.
• Valid and eligible are different. The page lists what Google documents, but only Google decides whether a page gets a rich result, and it can change its rules. The lists were read from Google's pages on 4 October 2026.
• Microdata and RDFa are not read. Only JSON-LD is.
• The page does not expand a custom @context. A block that defines its own terms is read, but names from it are not checked against schema.org.
• A text where an object is expected, such as a plain name for an author, is accepted by schema.org, and the page gives a note, not a warning. Google prefers the object form.
• The vocabulary is the schema.org release that was current in October 2026. A term that was added later is reported as unknown until the page is updated.
• Google's features have more rules than the ones listed, such as limits on content and on how a page must look. The page checks the properties and not the content.

Frequently asked questions