Schema Markup Validator
Free, no signup.
A schema block can look fine and still miss the one property blocking your rich result.
This validator checks yours in four layers — JSON-LD syntax, schema.org vocabulary,
Google's rich-result requirements, and cross-block @id graph resolution —
then hands you back a corrected, copy-pasteable version.
The fetched HTML is checked for JSON-LD and visible-content matches. JS-injected content cannot be evaluated; paste rendered markup when needed.
Example data — replace with your own
Requests are processed by our server and are not stored after processing. Only live-URL retrieval uses this service; pasted markup and all validation stay in your browser. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Sample report Example data — real, engine-verified result
Paste a small graph — an article, its author, and an unrelated product:
{
"@context": "https://schema.org",
"@graph": [
{ "@type": "BlogPosting", "@id": "#article", "headline": "How rich results actually work", "image": "https://example.com/hero.jpg", "datePublished": "2026-07-01T09:00:00Z", "author": { "@id": "#author" }, "publisher": { "@id": "#org" } },
{ "@type": "Person", "@id": "#author", "name": "Patrick Stox" },
{ "@type": "Product", "name": "Example Widget" }
]
} …and Validate returns three detected entities:
- The Product blocks its rich result — no
offers,review, oraggregateRating, so it lands in "Blocks rich result", the only tier that stops a rich result outright. - The dangling
@idis the subtle one.publisherpoints at#org, but no node with that@idexists anywhere in the graph — the graph-resolution layer catches it even though the JSON itself is perfectly valid. - The Person is fine, just irrelevant. It's valid schema.org with "no Google rich-result feature applies" — not every type needs to chase a rich result.
- Corrected JSON-LD fixes all of it at once — stubs for
offers,brand,sku,image,description,author.url, anddateModified, each markedADD:for you to fill in. - Building this from scratch instead of pasting? Use a schema generator to produce valid JSON-LD for a type from a simple form.
How to use it
- Paste your JSON-LD (starts with
or[) or a whole HTML page — Auto-detect figures out which you gave it, or force a mode with the tabs. - Press Validate. Detected entities appear first, then any issues grouped by how badly they hurt.
- Open Corrected JSON-LD to copy your markup back with stubs added for every
missing property — each line to fill in is marked
ADD:. - Use Copy shareable link to send a colleague the exact markup and its results.
Current target
Recent checks appear below. Use the star beside any saved site, page, or list to favorite it.
Create a named list
Target filled from your local choices.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Why the entity and issue verdicts were returned
Blocks rich result
Invalid markup or missing required properties — no rich result is possible until these are fixed.
Limits rich result
Valid, but missing recommended properties or soft issues that reduce eligibility or appearance.
Valid, but missed opportunity
Nothing wrong — properties or caveats that are worth knowing about.
Your input with stubs added for missing properties — every line to fill in is marked ADD:.
Input
Corrected JSON-LD
These checks compare selected user-facing schema values with the raw HTML's visible text. They cannot see content added by JavaScript after page load.
Why each content-match verdict was returned
Rate this tool
How it works
The validator runs four layers, in order, because each one only matters if the one before it passes:
- JSON-LD syntax — is it parseable JSON, in a valid
@context/@graphshape? - schema.org vocabulary — are the types and properties real, and used on types that actually define them?
- Google rich-result requirements — does each type carry the required and recommended properties Google documents for its rich result?
- @id graph resolution — do cross-block references (
@idpointers between entities) actually resolve, or dangle?
The validation engine runs in your browser. Markup you paste, including private drafts, is not uploaded or stored. Live-URL mode sends only the public URL to a guarded server endpoint to retrieve its HTML, then runs the same local checks against that response.
What the result groups mean
- Blocks rich result — invalid markup or a missing required property. No rich result is possible until you fix these.
- Limits rich result — valid, but a missing recommended property leaves eligibility or display on the table.
- Valid, but missed opportunity — nothing wrong; properties or caveats worth knowing about.
Common validation errors
Most broken rich-result markup is valid JSON but incomplete: a Product lacks an Offer price, an Article omits a headline or author, or an @id points to an entity that was never defined. The corrected output makes those gaps concrete with ADD: stubs, but only fill a stub with information that is genuinely shown to users.
That last check matters for both search quality and answer systems: schema is a claim about the page, not a hidden source of extra facts. In HTML and URL modes, this tool compares visible text with selected names, prices, and ratings so a mismatch is easy to investigate.
| Need | Best first check | Why |
|---|---|---|
| Draft or private markup | This Schema Validator | Detailed JSON-LD, vocabulary, graph, and corrected-output checks stay in your browser. |
| Published URL and Google rendering | Google Rich Results Test | Google fetches the live page and reports its own supported enhancements. |
| Which feature is one field away | Rich-Result Eligibility Checker | It groups the requirements by rich-result type and prioritizes near misses. |
One honest caveat the tool repeats: meeting every documented requirement makes a rich result possible, never guaranteed. Google decides at query time.
Features
- Four-layer validation: syntax → vocabulary → Google requirements → @id graph.
- Auto-detects JSON-LD vs full HTML; extracts every JSON-LD block from a page.
- Corrected, copy-pasteable JSON-LD with
ADD:stubs and an added-line diff view. - Shareable link that encodes your markup and its results.
- Local validation — pasted markup stays private; live-URL mode sends only the URL for HTML retrieval.
Limitations
It validates JSON-LD, the format Google recommends — not Microdata or RDFa. It checks the documented requirements for the rich-result types it knows; a novel or beta type may not be covered. Live-URL mode checks server-fetched HTML and does not execute page JavaScript, so markup injected by a tag manager or client-rendered app may be missing. Paste rendered HTML when needed, and use Google's Rich Results Test to confirm Google's rendered view of a published page.
Frequently asked questions
How is this different from Google’s Rich Results Test?
Google’s Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. Test fetches and renders a live URL, then reports which Google rich results it may qualify for. This validator runs its four validation layers locally in your browser. You can paste JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. or HTML (including private drafts), or ask the guarded server endpoint to retrieve a public URL’s HTML before the same local checks run. URL mode does not render JavaScript, so use Google’s test for the final rendered-page check.
Does valid schema guarantee a rich result?
No. Valid markup can satisfy documented markup requirements, but display also depends on supported feature policies, crawling, indexing, and the search context. Google does not guarantee a rich result.
Should I use JSON-LD, Microdata, or RDFa?
Google recommends JSON-LD, and it is the easiest format to maintain because the markup lives in a single script block separate from your HTML. This tool validates JSON-LD (including the JSON-LD blocks extracted from a pasted HTML page).
What does the @id graph check do?
Structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. often splits entities across blocks"Entity & identity schema" is a practitioner label — not an official Google or schema.org category, and not exhaustive of identity-capable schema.org types — for the three main types that declare who or what is behind a site: Organization, LocalBusiness, and Person. and links them with @id — for example an Article that references its author Person by @id. The graph check confirms those references actually resolve to a defined node instead of dangling, which is a common and hard-to-spot mistake.
Is my markup uploaded or stored anywhere?
Pasted markup is validated locally in your browser and is not uploaded or stored. If you use live-URL mode, only the public URL is sent to a guarded server endpoint so it can retrieve the page HTML; validation still runs locally. Fetched HTML may omit markup added later by JavaScript, so paste rendered HTML when you need to check it.
Feature requests for Schema Validator
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Common issues & how to fix them
- Errors JSON-LD cannot be parsed Fix: Fix the reported JSON syntax error—commonly a missing comma, quote, brace, or bracket—until the JSON-LD parses before evaluating schema properties.
- Warnings Schema context is missing or invalid Fix: Set the top-level @context to https://schema.org, or ensure each graph entity inherits that Schema.org context.
- Errors Schema type is missing Fix: Add the appropriate Schema.org @type to the affected entity, choosing the most specific type the page’s visible content supports.
- Errors Required property is missing Fix: Add the named required property with a value supported by the page, then validate that entity again.
- Errors Property value has the wrong type or format Fix: Change the flagged property to the expected scalar, URL, object, or array shape shown by the validator instead of coercing an unrelated value.
- Warnings Schema type is not recognized by the validator Fix: Correct a misspelled or obsolete @type to a recognized Schema.org type; remove the entity if no valid type accurately describes the content.
- Warnings Entity identifiers collide Fix: Merge entities sharing the same @id into one node, or assign distinct stable @id values when they represent different real entities.