JSON-LD Validator & Linter

Paste any JSON-LD block — or a full <script type="application/ld+json"> tag — and validate it instantly. The linter checks JSON parse integrity (reporting the exact error position), verifies @context and @type, and for 10 common Schema.org types checks required and recommended fields by name. Handles @graph arrays. No data leaves your browser.

How to use the JSON-LD Validator & Linter

Paste your JSON-LD into the textarea — either raw JSON or wrapped in the full <script type="application/ld+json">...</script> tag. Click Validate. The linter runs five checks in order:

  1. JSON parse: if the input can\'t be parsed as JSON, the error message and character position are shown.
  2. @context: must be present and equal to (or contain) "https://schema.org".
  3. @type: must be present and non-empty.
  4. Required fields: for known types (Product, Article/BlogPosting/NewsArticle, Recipe, Event, JobPosting, LocalBusiness, Organization, BreadcrumbList, FAQPage, HowTo) checks required fields and warns on missing recommended fields.
  5. @graph support: if the top-level object has a @graph array, each item is validated individually.

Results are displayed as a color-coded pass/warn/error list. Fix errors before shipping — Google\'s Rich Results Test will reject JSON-LD with parse errors or missing required fields.

What this validator checks and why

JSON-LD (JavaScript Object Notation for Linked Data) is a method of encoding Schema.org structured data as a self-contained JSON object embedded in a <script> tag. It is Google's preferred method for structured data because it can live anywhere in the document without touching the HTML markup.

A JSON-LD block must satisfy several layers of validity before Google will use it: first it must be syntactically valid JSON (even a trailing comma or unescaped quote breaks the parser); then it needs @context pointing to Schema.org and a @type to identify what entity is being described; and finally the type-specific fields must be present. Missing required fields cause the rich result to silently disappear — Google won't warn you in Search Console until several crawl cycles later. This validator surfaces those issues immediately.

The @graph pattern is used when a single page describes multiple entities (e.g., a BreadcrumbList and an Article at the same time). The validator detects the graph array and lints each node independently. Common causes of "missing field" warnings: author being a plain string instead of a Person object on Article types; offers missing on Product when aggregateRating is present; location missing on Event; step missing on HowTo.

Common use cases

  • Pre-deploy structured data check — Validate JSON-LD before merging a CMS template change — catches parse errors that would silently break all structured data on a page.
  • Debugging rich-result disappearance — When a rich result stops appearing, paste the current page's JSON-LD here to identify which required field was recently dropped.
  • CMS template audit — Paste the output of dynamic schema templates (Yoast SEO, RankMath, custom PHP) to verify the generated JSON-LD is always well-formed regardless of post data.
  • Agency QA workflow — Include this tool in structured-data QA checklists before handing off a site build to the client.
  • Learning schema.org types — The required/recommended field list per type serves as a quick reference for which properties actually matter for rich-result eligibility.

Frequently asked questions

Does this replace Google's Rich Results Test?
No — it complements it. This linter runs instantly in the browser and catches JSON syntax and field-coverage issues before you deploy. Google's test requires a live URL and also checks page rendering. Use both: this tool during development, Google's test for final verification.

Why does the validator show a warning instead of an error for some fields?
Warnings indicate recommended fields that improve rich-result eligibility but are not strictly required. Errors indicate fields without which Google will not generate the rich result at all. Fix errors first; work on warnings for maximum eligibility.

My JSON-LD passes here but Google still won't show the rich result — why?
Schema validity is one of several requirements. Google also checks that the content in the schema matches the visible page content, that the page has sufficient E-E-A-T signals for the type, and that the page isn't violating structured data policies (e.g., reviews on non-review pages).

Does the validator support nested @graph?
It handles a single top-level @graph array and validates each node inside it. Deeply nested or cross-referenced graph structures (using @id for references) are partially supported — the validator will check each inline node but won't resolve remote @id references.

What Schema.org types are covered?
Product, Article/NewsArticle/BlogPosting, Recipe, Event, JobPosting, LocalBusiness, Organization, BreadcrumbList, FAQPage, and HowTo. For other types, the tool still checks JSON syntax, @context, and @type — it just skips the field-coverage check.