Languages

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.

Built by Patrick Stox

Reproduce this result in an agent

Uses the same inputs as the result above. No request is made from this panel.

MCP tool

Arguments

 
  Set up the connector → 
 
 
    
 
 or fetch a live URL    
 
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. 
 
 
 Feedback 
 
 Report a bug 
Found something broken in Schema Validator? Let us know what happened — this goes straight to a private triage queue, not a public list.
 
      
 What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
   
 
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,
            or aggregateRating, so it lands in "Blocks rich
            result", the only tier that stops a rich result outright.
    •  
  • The dangling @id is the subtle one. publisher points
            at #org, but no node with that @id exists 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, and dateModified, each marked ADD: 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
 
     
  1. 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.
    2.  
  2. Press Validate. Detected entities appear first, then any issues grouped by how
            badly they hurt.
    3.  
  3. Open Corrected JSON-LD to copy your markup back with stubs added for every
            missing property — each line to fill in is marked ADD:.
    4.  
  4. Use Copy shareable link to send a colleague the exact markup and its results.
    5.  
 
 
 
       
     
       
 
How it works
 

The validator runs four layers, in order, because each one only matters if the one before it
          passes:

 
     
  1. JSON-LD syntax — is it parseable JSON, in a valid @context/@graph
shape?
    2.  
  2. schema.org vocabulary — are the types and properties real, and used on types that
            actually define them?
    3.  
  3. Google rich-result requirements — does each type carry the required and
            recommended properties Google documents for its rich result?
    4.  
  4. @id graph resolution — do cross-block references (@id pointers between
            entities) actually resolve, or dangle?
    5.  
 

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.
 
 
 
 Which validator should you use?  
 NeedBest first checkWhy 
   
 Draft or private markup This Schema ValidatorDetailed JSON-LD, vocabulary, graph, and corrected-output checks stay in your browser. 
 Published URL and Google rendering Google Rich Results TestGoogle fetches the live page and reports its own supported enhancements. 
 Which feature is one field away Rich-Result Eligibility CheckerIt groups the requirements by rich-result type and prioritizes near misses. 
  
 
 
 Source: Tool guidance; Google decides live rich-result display. · Updated: 2026-07-12 
 
 

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.
 
 
← All free tools
 
 
   
Next stepSchema Markup Generator — generate valid JSON-LD for the page instead of hand-editing markup.

People also explore
ToolRich-Result Eligibility CheckerToolEntity Coverage AnalyzerToolGoogle Knowledge Graph ExplorerArticleJSON-LDArticleItemList SchemaArticleImageObject Schema
 
 
 
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.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
   
   
 
Where this tool helps
Common use cases
Preflight draft JSON-LD before publishing
Validate private or in-progress markup locally for JSON syntax, schema.org vocabulary, documented Google requirements, and cross-node references.
Find the field that blocks a rich result
Separate blocking required-property failures from recommended-property limits and lower-priority opportunities instead of treating every warning alike.
Debug connected entity graphs
Inspect detected nodes and @id relationships to find duplicate identifiers, dangling references, and references that resolve to the wrong entity type.
Compare schema claims with visible HTML
Paste HTML or fetch a fictional public page to investigate whether selected names, prices, and ratings in schema also appear in the raw visible content.
Create an implementation handoff
Copy corrected JSON-LD, share bounded input state, or export the complete entity and issue record for developers and reviewers.
Watch the full workflow
Schema Markup Validator walkthrough
Read the transcript

      
      

        
Schema Markup Validator

        

        
This beginner walkthrough explains schema markup and J-S-O-N-L-D, validates the built-in fictional example, and reads the results in priority order. We will separate one rich-result blocker from softer improvements, trace a broken entity link, review corrected starter output, and check a fictional page whose schema price differs from its visible price. No customer markup or live business is used.

      

      

        
Step 1

        

        
Schema markup is machine-readable information that describes things on a page, such as an article, person, product, price, or organization. J-S-O-N-L-D is the common script format used to publish it. This validator checks whether supplied markup can be read, uses implemented schema dot org terms, meets tracked Google feature requirements, and connects referenced items correctly. Pasted drafts stay in the browser.

      

      

        
Step 2

        

        
Use it before publishing new markup, when a rich-result requirement is missing, when linked entities do not connect, when schema claims may disagree with visible page text, or when developers need a corrected starting point and full issue export. The report separates blockers, softer limits, and optional opportunities so the team can fix the highest-priority evidence first.

      

      

        
Step 3

        

        
Auto-detect decides whether you pasted J-S-O-N-L-D or a full H-T-M-L document. The other tabs can force a mode when you already know the format. You can paste private draft markup, load the built-in example, or fetch one public U-R-L. U-R-L mode reads the returned raw H-T-M-L and does not render JavaScript.

      

      

        
Step 4

        

        
Select Try an example. The page loads a labeled fictional graph and validates it in a separate browser worker. A graph simply means several structured-data items can refer to one another. This result contains one Blog Posting, one Person, and one Product.

      

      

        
Step 5

        

        
The summary reports three entities, which means three described items. It finds one Product, no Product Groups, and no Offers. The type chips keep the per-type counts visible, while J-S-O-N and C-S-V exports preserve the full entity and issue record. These are counts inside the supplied markup, not traffic or search-performance metrics.

      

      

        
Step 6

        

        
All three items use valid implemented schema dot org vocabulary. That means the types and properties are recognized. Separately, the Blog Posting meets the tracked Article requirements, the Person has no applicable Google rich-result feature, and the Product misses a Product requirement. Valid vocabulary and complete feature eligibility are different questions.

      

      

        
Step 7

        

        
The highest-priority group contains one issue. For this tracked Product result, the Product needs at least one Offer, Review, or Aggregate Rating. The blocking group is for markup that cannot be read, unsupported terms, or missing required information that prevents the intended feature baseline. Confirm which truthful property applies before adding it.

      

      

        
Step 8

        

        
The next group contains seven softer findings: the author lacks a U-R-L, the article lacks a modified date, the Product lacks four recommended fields, and the publisher reference has no matching item. These gaps can reduce completeness or reveal a graph problem, but the interface correctly keeps them below the Product blocker instead of pretending every warning has equal impact.

      

      

        
Step 9

        

        
An at-I-D gives a structured-data item a reusable identifier. Another item can point to that identifier instead of repeating all its properties. The graph shows three detected entities and two references. The article’s author reference reaches the defined Person, but its publisher points to hash org, which has no matching node. Valid J-S-O-N syntax alone would not catch that broken connection.

      

      

        
Step 10

        

        
Corrected J-S-O-N-L-D keeps the supplied graph and adds highlighted A-D-D placeholders for supported missing properties. Copy it only as an implementation starting point. Never publish the placeholder text or invent a rating, price, author, image, or organization. Replace every addition with a true value supported by visible page content.

      

      

        
Step 11

        

        
After validation, Copy shareable link places the exact input and mode in the link after the hash sign instead of storing it on the server. The tool rejects an encoded input that is too large. Use share links for small, non-sensitive review cases. The separate M-C-P action can hand the input to an available connected workflow.

      

      

        
Step 12

        

        
Full J-S-O-N preserves the structured result for another system. C-S-V turns entities and findings into a spreadsheet-friendly table. Use these exports when a developer or reviewer needs the complete entity, priority group, issue code, property, node, and message instead of only a screenshot.

      

      

        
Step 13

        

        
U-R-L mode sends the public address to the guarded fetch service, then validates the returned H-T-M-L. The page clearly warns that markup added later by JavaScript will not appear. If the raw response is not the evidence you need, paste rendered H-T-M-L or use a tool that compares rendered output.

      

      

        
Step 14

        

        
Enter the reserved fictional blue-trail-shoe address and select Fetch and validate. The visible status confirms which page was checked. The returned raw H-T-M-L describes one Product, its Brand, and an Offer. Because this is a reserved fictional address, no customer or live business data appears in the walkthrough.

      

      

        
Step 15

        

        
The fetched report finds three entities: Product, Brand, and Offer. The Product meets the implemented schema and tracked feature checks, and the graph contains one Offer. That does not guarantee a search display. It means only that the supported markup checks pass for this fictional input.

      

      

        
Step 16

        

        
One consistency issue remains in the softer group. The schema claims a price of one hundred twenty-nine dollars, while the fictional visible H-T-M-L shows one hundred thirty-nine. The tool labels this Content inconsistency—verify. It is an investigation cue, not automatic proof that eligibility is blocked, a policy was violated, or anyone intended to mislead.

      

      

        
Step 17

        

        
The evidence drawer names the schema price it searched for, says that value was not found in the fetched visible text, identifies raw H-T-M-L matching as the evidence source, and provides a fix-and-verification path. Align the schema price with what users can see, then validate the released rendered page again.

      

      

        
Step 18

        

        
The validator works in layers because later conclusions depend on earlier ones. First it checks readable J-S-O-N syntax, then implemented schema dot org terms, then tracked Google feature requirements, and finally links between entities. H-T-M-L mode can also compare selected schema values with raw visible text. Each finding comes from an engine rule and observed input evidence.

      

      

        
Step 19

        

        
Start with Blocks rich result, which covers unreadable markup, unsupported terms, and missing required properties. Next review Limits rich result for incomplete or investigative work. Finish with Valid, but missed opportunity for optional context. This priority order makes a long issue list useful without claiming every suggestion has the same effect.

      

      

        
Step 20

        

        
The tool includes automatic input detection, separate-worker validation, grouped repeated issues, entity and type totals, an at-I-D relationship view, corrected-output differences, expandable evidence, full exports, bounded share links, Schema Generator handoffs, M-C-P access, and a rendered-comparison next step when raw H-T-M-L does not contain expected Product markup.

      

      

        
Step 21

        

        
The implemented and dated rule catalog is not a promise to cover every schema term or search feature forever. U-R-L mode does not render JavaScript. Large results are grouped and limited on screen. Corrected placeholders require human truth, and passing the checks does not guarantee display. Validate the released rendered page in Google’s Rich Results Test, then monitor actual search behavior separately.

      

      

        
Validate the released truth—not only the draft’s shape.

        

        
Fix only issues supported by the page and business facts. Replace every generated placeholder with a truthful value that users can also verify, then validate the final rendered H-T-M-L again. Use Google’s Rich Results Test for the released page. Valid markup can make a page eligible for consideration; it never guarantees that Google will show a rich result.

      

    
 
          
 
Common issues & how to fix them
 
     
  •  Error 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. 
  •  Warning 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. 
  •  Error 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. 
  •  Error Required property is missing Fix: Add the named required property with a value supported by the page, then validate that entity again. 
  •  Error 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. 
  •  Warning 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. 
  •  Warning 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. 
    •