What the JSON-LD validator does

Structured data usually comes from a plugin, a template or a hand-written block, and one stray comma makes the whole block unreadable. This tool splits your input into blocks, parses each one and lists every finding with its location: block number, JSON Pointer path, line and column.

Use it as a pre-release check, to inspect what a plugin really outputs, or to confirm that dates and author fields are well formed. It does not generate markup; the related schema generator does that.

How to use

  • Paste either plain JSON-LD or the HTML source of a page. Input starting with < is read as HTML and each application/ld+json block is checked separately.
  • Press Validate. A syntax error in plain JSON appears in the error box with line and column; in HTML mode a broken block becomes an error row and the other blocks are still checked.
  • Read the layer column of the findings table: syntax, JSON-LD structure, Schema.org value types, Google profile and scope notes are kept apart.
  • Copy the text report or download the JSON report. After editing the input, validate again.

Three validation layers

The first layer is JSON syntax: trailing commas, single quotes, comments, unterminated strings and raw control characters are reported with their position. Duplicate keys, which most JSON readers silently overwrite, are flagged too. Keys such as __proto__ stay plain data and are never merged into objects.

The second layer is JSON-LD structure: top-level object or array, @graph, @context, @type, @id and unknown @ keywords. Local @id references are resolved with a cycle guard. The third layer applies selected rules in two parts:

LayerWhat is checkedExample finding
Schema.org value typesDates, durations, URLs, numbers, currencies and enumerations2026-02-30 is not a real date
Google profileRequired and recommended properties documented for one Google featureimage is recommended for Article
ScopeTypes without a rule profile and contexts that are not downloadedUnknown type, external @context

A missing Google-required property does not make the markup invalid Schema.org; it only means one documented condition for that Google feature is not met, so it is a warning. A missing recommended property is only a note, never an error.

Supported types

TypeChecks
Article, BlogPosting, NewsArticleNo Google-required properties; author, date, headline and image recommendations
BreadcrumbList, ListItemAt least two items; position, name and item; the last item may omit item
FAQPage, Question, AnswerQuestion and answer structure; an information note on Google visibility
Product, Offer, AggregateOffer, Review, AggregateRatingProduct and review snippet properties, price and currency format
LocalBusiness and subtypes, OrganizationName and PostalAddress; contact and location recommendations
WebSite, WebPage, Person, Event, RecipeSite name, event and recipe properties; basic checks only for WebPage and Person

Other types still get the JSON and JSON-LD checks; their type rules are reported as out of scope. Each rule profile stores its source URL, check date and version, which the downloaded report includes. The Google profiles were read from the Google Search Central structured data documentation on 28 September 2026.

Worked example

This Turkish blog post markup has no image and an impossible date:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Hızlı web deneyimi ilk karardan başlar",
  "datePublished": "2026-02-30",
  "author": {"@type": "Person", "name": "Yunus Emre Balçın"}
}

The report shows a Schema.org value-type error at /datePublished, because February has no 30th day. Google profile notes appear for image, dateModified and author.url: recommendations that do not make the JSON-LD invalid. The Turkish headline is kept as written. The Load example button opens an HTML sample where the last breadcrumb without item is accepted and only noted.

Limits of Google eligibility checks

This tool does not decide on Google's behalf. Even with every listed property present, Google decides whether a rich result appears; content quality, match with visible content and policy compliance cannot be measured locally. The report never states approval or eligibility.

FAQPage is a special case: Google announced in its Search updates log that FAQ rich results are no longer shown from 7 May 2026. Well-formed FAQ markup is treated as semantic description only. Site name data from WebSite is read only on the home page. For a final check, use Google's Rich Results Test and Search Console.

Limits and privacy

  • Input is limited to 1 MiB, nesting depth to 64 and the node count to 10,000.
  • External @context URLs are not downloaded and no JSON-LD expansion or RDF validation is done; you get a scope warning instead.
  • The full Schema.org vocabulary is not checked, so misspelled property names are not always caught.
  • HTML is never executed or inserted into the page; blocks are found with a text scan. Markup added later by JavaScript is not visible.
  • Your input is processed in your browser and not sent to a server; it is added to a share link only if you choose to.

Frequently asked questions

If the report is clean, will Google show a rich result?

Nobody can guarantee that. The tool checks syntax, structure and selected rules locally; Google decides on rich results.

Why is a missing recommended property not an error?

Google lists them separately, and leaving them out does not invalidate the markup. A missing image on an Article is therefore shown as a recommendation.

I use an external @context. Why do I get a warning?

The tool makes no network requests, so it cannot download the context or know its mappings. Types are read as Schema.org short names.

Can I check several JSON-LD blocks at once?

Yes. Each application/ld+json block in pasted HTML is numbered, an error in one block does not stop the others, and positions refer to the original HTML.

Is my input stored anywhere?

No. Validation runs in your browser; nothing is sent to a server or written to local storage.

Published: · Updated: