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).

Why a passing validation is not the same as a rich result

It is worth being blunt about what this validator can and cannot promise. A green result means your JSON-LD is syntactically sound, structurally complete, and carries the fields Google asks for. It does not mean a rich result is guaranteed to appear. Google decides per query and per page whether to draw the enhanced treatment, weighing content quality, page authority, and whether the markup honestly reflects the visible page. Valid schema is the entry ticket, not the prize.

This matters because people often validate their schema, see green, and then panic when no stars or no carousel show up in search. The validator has done its job; the missing rich result is usually a content or trust problem, not a markup one. Keep the two questions separate. First, is my schema valid, which this tool answers definitively. Second, has Google chosen to show a rich result, which only Search Console and the live SERP can tell you over time.

Markup must match the visible page

One rule underpins all of structured data: the schema has to describe what a human actually sees on the page. Marking up a review rating that does not appear anywhere on the page, claiming a price the page does not show, or describing an FAQ that is not present in the content is a policy violation that can trigger a manual action and strip your rich results entirely. The validator checks that your JSON is well formed; it cannot check that you are telling the truth.

So treat every field you fill in as a promise that the corresponding thing exists on the page. If your Product schema lists an aggregateRating, real reviews must be visible. If your Article lists an author, that author should be credited on the page. Aligning the markup with the rendered content is not just about avoiding penalties; it is how you keep the data trustworthy for the AI systems that increasingly read it as fact.

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.

How to read the validator output line by line

The output is split into three buckets so you always know what is fatal and what is cosmetic. Parse errors come first because nothing else can run until the JSON is structurally sound. Each parse error names the offending character and the line and column where the parser gave up, so you can jump straight to the trailing comma or smart quote instead of re-reading the whole block.

Below parse errors sit the validation errors. These are properties that schema.org or Google flatly require and that your block is missing or has set to the wrong data type, for example a price given as text when an offer expects a number, or an author given as a bare string when a Person object is required. Treat every red error as a deploy blocker; a single one can suppress the entire rich result.

Last come the warnings, shown in a softer color. Warnings mean the block is valid and will be accepted, but Google recommends a field you have not supplied, or you have included a property that does not belong on this type and will simply be ignored. Warnings are your click-through-rate to-do list rather than an emergency, so work them after every error is cleared.

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.

Multiple schema blocks and the @graph pattern

Most real pages carry more than one schema block. A product page might have Product, BreadcrumbList, and Organization all at once. You can keep them as separate script tags, or bundle them into a single block using an @graph array where every node lists its own @type. The validator accepts both styles and checks each node independently, but it also looks at how they connect.

The reason the @graph pattern is worth learning is that it lets nodes reference each other by an @id instead of repeating the same Organization object three times. Your Article can point its publisher at the same @id your Organization node defines, which keeps the data consistent and smaller. The validator flags dangling references, where an @id is pointed at but never defined, because Google treats those as broken links between entities and may drop the connection.

When two blocks describe the same thing with different values, you create a conflict the validator cannot resolve for you. If one block says the price is 19.99 and another says 29.99 for the same product, Google has to guess, and guessing usually means no rich result at all. Keep one source of truth per entity and reference it everywhere else.

How clean JSON-LD helps you in AI search

Structured data is no longer just about the blue-link rich result. AI Overviews, ChatGPT search, Perplexity, and Gemini all read JSON-LD to understand what an entity is, who published it, and when it was last updated. A clean, validated block is the most machine-readable summary of your page that exists, and these systems lean on it heavily when deciding whether to cite you and how to describe you.

That raises the stakes on accuracy. A date in the wrong format used to just cost you a Top Stories slot; now it can mean an AI engine reports stale information about your business because it could not parse your dateModified. Validating before every deploy is the cheapest insurance you have against an AI assistant confidently repeating wrong facts about your brand to a customer.

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.