Structured Data Validator

Using the Structured Data Validator

1. Paste your JSON-LD - either the raw object or the full <script type="application/ld+json">...</script> wrapper. The validator strips the script tag automatically before parsing.
2. Click "Format" to pretty-print the input, which makes misplaced braces and trailing commas visible immediately.
3. Click "Validate" - the tool runs a three-stage check: JSON syntax via JSON.parse, schema.org shape via a ruleset for known types, and Google rich-result hints via a second ruleset derived from Google\'s documentation.
4. Review the issue list - errors are blocking (invalid JSON, missing required field, wrong @context), warnings are non-blocking (recommended field missing, suspicious value format).
5. Fix and revalidate - the tool reparses on each click, so you can iterate inline until the error list is empty.

What the Validator Actually Checks

Stage one is JSON parsing: JSON.parse in V8, SpiderMonkey, or JavaScriptCore catches trailing commas, unquoted keys, single quotes, and other syntax errors that prevent the block from being machine-readable. Stage two verifies the @context is one of the accepted schema.org URIs (https://schema.org, http://schema.org, or an extended context with schema.org as a base). Stage three runs a per-type ruleset: for Product it checks for name and either image or offers; for Recipe it checks for recipeIngredient, recipeInstructions, and image; for Article it checks for headline (with a 110-character soft limit per Google) and author; and so on for the dozen most common types.

The validator does not emulate Google\'s full parsing pipeline - that would require replicating Google\'s proprietary parser, which is not publicly specified. What it does is encode the rules that Google\'s Rich Results Test and Schema Markup Validator enforce publicly, so a block that passes this validator will almost always pass those two external validators as well.

Typical Use Cases

• Debugging why a page\'s rich result disappeared after a content update - often a required property got accidentally removed by a template edit.
• Validating structured data generated by a CMS plugin before publishing, especially when the plugin\'s output is not trivially human-readable.
• Pre-flight checking JSON-LD emitted by a server-rendered framework (Next.js, Astro, Nuxt) against what the schema rules actually require.
• Teaching developers unfamiliar with schema.org what counts as "valid" by showing them structured error messages for common mistakes.
• Auditing competitor structured data pasted from View Source, to understand why their rich results render while yours do not.

Common JSON-LD Mistakes

• Trailing commas - legal in JavaScript object literals since ES2017, illegal in JSON forever. Copying a template literal from a JS file into a validator often produces this.
• Unescaped quotes inside strings - a description field with an apostrophe written as "it's" inside a string delimited by single quotes breaks the JSON.
• Wrong @type casing - schema.org types are PascalCase (Article, LocalBusiness). article or ARTICLE fails validation silently in some parsers.
• Dates in non-ISO format - "datePublished": "April 22, 2026" parses as a string but fails ISO 8601 validation. Use "2026-04-22T10:30:00Z".
• Numbers quoted as strings - "price": "19.99" is correct per schema.org (prices are strings to preserve currency formatting), but "ratingValue": "4.5" works only because schema.org explicitly allows either number or string. Some properties (like width on ImageObject) strictly want numbers.
• Orphan nested objects without @type - "author": {"name": "Alice"} parses but Google flags it as ambiguous. Always include "@type": "Person" or "@type": "Organization".
• Duplicate @context on nested objects - the @context declaration should appear only on the outermost object; nested objects inherit it.

JSON-LD and Schema.org Background

JSON-LD is a W3C Recommendation (REC-json-ld-1.1) that formalizes how JSON can represent linked-data graphs using @context, @type, and @id as reserved keywords. Schema.org is a separate vocabulary, maintained as a joint project by Google, Microsoft, Yahoo, and Yandex since 2011, with releases roughly quarterly. The two are orthogonal: JSON-LD is a serialization format; schema.org is a specific vocabulary you can serialize in JSON-LD. You could in principle use schema.org in Microdata or RDFa - the vocabulary does not require JSON-LD - but JSON-LD is what search engines parse most reliably. The canonical reference for each type and its properties lives at schema.org/<TypeName>; Google\'s filtered rich-result documentation lives at developers.google.com/search/docs/appearance/structured-data.

Alternatives and Their Tradeoffs

Google\'s Rich Results Test (search.google.com/test/rich-results) is authoritative for Google rich-result eligibility - it actually fetches your URL, runs Google\'s parser, and shows a preview of the rich result. The drawback is that it needs a live URL and only covers types Google renders. The Schema.org validator at validator.schema.org runs a stricter vocabulary-level check, useful for Bing, Yandex, and generic schema correctness. For CI/CD, tools like schema-dts (TypeScript types for schema.org) let you catch structural errors at compile time before anything hits production. This validator wins for quick local iteration on raw JSON-LD snippets, validating drafts that are not yet deployed, and showing human-readable error messages without signing into any Google account.