What this JSON-LD validator does

Paste a JSON-LD block, get a verdict in under a second. The validator runs three checks: JSON syntax (is the structure parseable), schema.org compliance (does the @type exist, are required fields present), and Google rich-result eligibility (are the fields Google specifically requires actually filled in). If any layer fails, you see the exact path and a plain-language explanation of what to change.

Use this validator before deploying schema changes to production. The most common cause of broken rich results is a syntax error introduced during a template edit that nobody catches until traffic mysteriously drops a week later. Run any new schema through here first.

JSON syntax errors that break everything

JSON is unforgiving. A trailing comma after the last field in an object, a missing comma between fields, a curly quote pasted in from a Word document, or an unescaped backslash in a URL all break the parse silently. Google does not log these in Search Console. The schema simply does not exist as far as crawlers are concerned.

This validator surfaces the exact error message your JSON parser would report, plus the byte offset where parsing failed. The most common patterns: trailing commas (remove them), single quotes instead of double quotes (JSON requires double), missing commas between sibling properties, and unescaped quotes inside string values (escape them with a backslash).

Schema.org compliance

Once syntax is valid, the validator checks whether your @type is a real schema.org type. Typos like "Articl" or "Prodcut" silently fail. Custom @types not in the vocabulary fail. Old types that have been deprecated fail. The validator catches all three.

Then it checks required properties for that type. Article requires headline. Product requires name. LocalBusiness requires address. The validator follows the latest schema.org definitions, including property requirements that have changed over time. If your schema was written against the 2019 spec, some fields now mandatory may be missing.

Google's rich-result requirements (often stricter than schema.org)

For rich results to actually appear in search, Google requires more than schema.org's minimum. Google publishes per-type documentation listing additional required and recommended fields. Article needs author and datePublished for Top Stories. Product needs offers with price for the price-in-SERP treatment. Recipe needs cookTime, recipeYield, and recipeIngredient for the recipe carousel.

This validator flags the Google requirements separately from schema.org's. A schema can be 100% schema.org compliant but still fail to produce rich results because it omits Google's additional recommended fields. The output distinguishes errors (schema is broken) from warnings (schema is technically valid but rich results will not appear).

Common mistakes specific to JSON-LD

Missing @context is the cardinal sin. Every JSON-LD block must start with "@context": "https://schema.org" (or include it inline on each @type). Without it, the entire block is unparseable as schema.

Nested types without their own @type are silently ignored. If you have an author property, it cannot be just a string of the name; it must be an object with @type: Person and a name property. Same for organization, image, and address. The validator catches these.

Date formats are wrong more often than not. ISO 8601 is required: "2026-01-15" for dates, "2026-01-15T14:30:00-08:00" for datetimes with timezones. Anything else, including locale-specific formats, fails parsing.

URL fields must be absolute. Relative paths like "/about" or schemes without a host like "https://" alone get rejected. Use full URLs with protocol and domain.

JSON-LD versus other formats

This validator tests JSON-LD specifically. If you are using Microdata or RDFa, copy the equivalent JSON-LD and validate that instead. JSON-LD is what Google now recommends for all new schema implementations because the format is decoupled from your visible HTML, which means template changes do not break it.

If you must keep Microdata for legacy reasons (older WordPress themes, hand-written HTML from a decade ago), use Google's Structured Data Linter or the Schema Markup Validator at validator.schema.org. They handle non-JSON-LD formats. For new code, switch to JSON-LD and forget Microdata exists.

What to do after validation passes

Validation passing means the schema is syntactically and structurally correct. It does not guarantee rich results will display. After validation, run the same JSON through Google's Rich Results Test at richresults.google.com to confirm rich-result eligibility for your specific result type. Then deploy, wait a few days, and check Search Console's Enhancements section to see whether Google has actually parsed and indexed the new schema.

Rich results may still not appear even with valid schema and confirmed eligibility. Google decides per query whether to display the rich treatment based on factors like content quality, page authority, and query intent. If your schema is clean and Search Console confirms eligibility, the rest is patience and content quality.