Schema Markup Validator
A free JSON-LD checker. Paste your structured data and test it against Schema.org and Google's rich-result rules: required fields, recommended fields and eligible types, instantly in your browser, nothing uploaded.
Paste your markup and click Validate to see errors, warnings, and rich-result eligibility.
A schema markup validator checks the structured data on a page for errors before a search engine or AI model reads it. This one takes JSON-LD, confirms it parses, checks for a Schema.org "@context" and an "@type" on every entity, then tests the required and recommended fields Google documents for fifteen rich-result types. It runs in your browser and uploads nothing.
How the schema markup validator works
The tool is a linter for one syntax, JSON-LD, and one vocabulary, Schema.org. It parses your markup, walks every entity it finds, and grades each miss by what it would cost you: a parse failure or a missing required field is an error, a missing recommended field is a warning. No account, no crawl, no upload.
- 1
Paste the JSON-LD, or the whole script tag
Copy the structured data from your page source. A bare object, an array, an "@graph" document, or the complete <script type="application/ld+json"> element all work; the validator strips the tag and reads what is inside.
- 2
Click Validate
The checks run in your browser. Nothing is sent to a server, so markup for an unreleased product, a draft article or a staging site is safe to paste.
- 3
Read the verdict, then the detected types
The top line says valid or invalid. "Detected types" lists every "@type" found; "Rich-result eligible" lists the types with every required field present. Detected but not eligible means something is missing.
- 4
Fix errors before warnings
ERROR means the JSON does not parse, "@context" or "@type" is missing, or a required field is absent. WARNING means a recommended field is missing: valid, but a rich result or an AI answer has less to work with. INFO is the confirmation line when everything passes.
- 5
Re-run, then confirm the live page
Validate until the top line reads valid. Publish, then run the live URL through Google’s Rich Results Test once; that tool sees the rendered page, this one sees only the text you pasted.
Every check this validator runs
The exact checks, in execution order. A syntax error stops the run, because nothing after it can be trusted. Any error makes the markup invalid; warnings alone still pass, and a clean run opens with an info line listing every type found.
| Check | Severity | Why it matters | How to fix |
|---|---|---|---|
| Input is not empty; script wrapper is stripped | Error if empty | Whitespace-only input is a common paste mistake. If you pasted a whole script element, the tool extracts the text between the tags before parsing. | Paste the markup or the tag; both work. Only the first script block in the paste is read. |
| JSON parses | Error, stops the run | JSON-LD is JSON first. A trailing comma, an unescaped quote inside a string, a comment, or single quotes makes a parser give up. | Read the position in the syntax-error message. Remove trailing commas, escape inner quotes as \", delete comments, use double quotes throughout. |
| "@context" names Schema.org | Error | The context says which vocabulary your property names belong to; without it "name" and "offers" have no agreed meaning. Any string containing "schema.org", or a context object, on the root passes. | Add "@context": "https://schema.org" to the root object. With "@graph", the context still belongs on the outer object. |
| At least one "@type" | Error | An object without a type is a bag of properties nobody can act on. The tool looks for typed entities at the root, in a root array, and inside "@graph". | Give the root object an "@type". Every entry in an "@graph" needs one. |
| Required fields present, per type | Error | For fifteen types (Product, Offer, Article, NewsArticle, BlogPosting, FAQPage, Question, BreadcrumbList, Organization, LocalBusiness, Recipe, Event, Review, VideoObject, WebSite) the tool checks the fields Google marks as required. Absent, null or empty-string values count as missing. | Add the named field. The message lists which fields are missing for which type. |
| Recommended fields present, per type | Warning | The same types have recommended fields, such as image and author on Article, or offers and brand on Product. Missing them leaves a rich result or an AI answer with less to show. | Add what you honestly have. Do not invent a rating to clear a warning. |
Common JSON-LD failures and how to fix them
Most markup fails for one of five reasons, and only two of them look wrong to the eye. Failing version on the left, passing version on the right.
Fails: no @context
{
"@type": "Organization",
"name": "Acme",
"url": "https://acme.com"
}Passes
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Acme",
"url": "https://acme.com"
}Without "@context" the property names have no vocabulary, so a consumer cannot know that "name" means schema.org/name. The validator errors with "Missing @context".
Fails: trailing comma and unescaped quote
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Aeron Chair "Classic"",
"sku": "AER-001",
}Passes
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Aeron Chair \"Classic\"",
"sku": "AER-001"
}Two syntax faults: an unescaped double quote inside a string, and a comma after the last property. Either one stops the parser, and the validator reports a JSON syntax error with the position.
Silently under-checked: wrong @type casing
{
"@context": "https://schema.org",
"@type": "product",
"name": "Aeron Chair"
}Passes with field checks
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Aeron Chair"
}Schema.org type names are case-sensitive: Product, not product; FAQPage, not FaqPage. The lowercase version parses, so the validator reports valid JSON-LD with detected type "product", but runs no required-field checks and never lists it as rich-result eligible.
Fails: required field missing
{
"@context": "https://schema.org",
"@type": "Article",
"title": "How to validate schema markup",
"author": { "@type": "Person", "name": "Priya Rao" }
}Passes
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to validate schema markup",
"author": { "@type": "Person", "name": "Priya Rao" },
"datePublished": "2026-07-24",
"image": "https://acme.com/img/schema.png"
}Article requires headline, not title. The left-hand block is valid JSON with a valid context and type, and it still errors: "Article: missing required field — headline". The right-hand block also adds datePublished and image, clearing two recommended-field warnings.
Passes here, fails in Google: string where an object is expected
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Aeron Chair",
"offers": "1395 USD",
"brand": "Herman Miller"
}Passes everywhere
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Aeron Chair",
"brand": { "@type": "Brand", "name": "Herman Miller" },
"offers": {
"@type": "Offer",
"price": "1395.00",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock"
}
}This validator checks that "offers" is present, not that it is an Offer object, so the left-hand block passes. Google’s Rich Results Test reads "offers" as an Offer and rejects a bare string, and an AI shopping agent looking for a price and a currency finds neither. Dates behave the same way: write "2026-07-24", not "July 24, 2026".
JSON-LD vs microdata vs RDFa: why JSON-LD is what to validate
Schema.org vocabulary can be written into a page three ways. They describe the same entities; they differ in where the markup lives and how hard it is to extract.
| Format | Where it lives | How a crawler reads it | Trade-off |
|---|---|---|---|
| JSON-LD | One <script type="application/ld+json"> block, separate from the visible HTML. | Find the script tag, parse the JSON. No DOM traversal. | Easiest to generate, validate and extract; the format Google’s guidelines recommend. Its weakness is drift from the visible page. |
| Microdata | Attributes (itemscope, itemtype, itemprop) on the elements that display the data. | Walk the DOM and assemble entities from scattered attributes. | Cannot drift from the visible content, because it is the visible content. Painful to maintain in component-based front ends. |
| RDFa | Attributes (vocab, typeof, property) on elements, from the W3C RDFa standard. | Walk the DOM, as with microdata, with a richer model for linking entities. | Most expressive of the three and the least used for Schema.org on commercial sites. |
JSON-LD is the format to validate because it is the format to ship. Google recommends it, most CMS and e-commerce platforms emit it by default, and it is the only one of the three that can be checked without rendering the page. A retrieval agent answering a question has a context budget, and one self-contained block that says what the page is, who published it and what it costs is the cheapest summary to extract. This tool reads JSON-LD only; Google’s Rich Results Test and the Schema.org validator read all three formats from a live URL.
Which schema types matter for AI answers
Not every type earns a rich result, and Google has narrowed FAQ and HowTo rich results since 2023. The table reads each type two ways: what it signals to a model, and what this validator checks for it.
| Type | What it signals to a model | What this validator checks |
|---|---|---|
| Organization | Who is speaking. Name, url, logo and sameAs give a model one unambiguous identity to attach the rest of the site to. | Required: name. Recommended: url, logo, sameAs, contactPoint. |
| Article, NewsArticle, BlogPosting | What this page claims and who stands behind it. headline, author, datePublished and publisher are the fields a citation is built from. | Required: headline. Recommended: image, author, datePublished, publisher; Article also dateModified. |
| FAQPage and Question | Explicit question-and-answer pairs, the shape an answer engine is trying to produce. Google limits the FAQ rich result to a narrow set of sites; the markup remains valid, machine-readable Q&A. | FAQPage requires mainEntity. Question requires name and acceptedAnswer. |
| HowTo | An ordered procedure with named steps. Google retired the HowTo rich result in 2023; the type still marks the page as a sequence to follow. | Detected and listed. Not in the required-field table, so no field checks run. |
| Product and Offer | What is for sale, at what price, in what currency, and whether it is in stock. gtin and sku let a model match your listing to the same product elsewhere. AI shopping agents read these fields before your copy. | Product requires name; recommended image, offers, aggregateRating, review, brand, sku, gtin. Offer at the root or in @graph requires price and priceCurrency. |
| DefinedTerm | A term and its definition. On a glossary page it gives a model a definition it can quote as one, rather than infer from prose. | Detected and listed. Not in the required-field table, so no field checks run. |
This validator vs Google’s Rich Results Test vs the Schema.org validator
Three tools share the name and do three different jobs.
| Tool | What it tests against | Input | Best for |
|---|---|---|---|
| This JSON-LD checker | JSON syntax, Schema.org context and type, and Google’s required and recommended fields for fifteen rich-result types. | Pasted JSON-LD or a script tag. Runs in the browser, nothing uploaded. | Fast iteration while you write or template the markup. Drafts, staging, unreleased pages. |
| Google Rich Results Test | Google’s own rich-result features only. Reports eligibility and renders a preview. | A live URL, which Google fetches and renders, or a pasted snippet. | The final check on a published page, and the only way to confirm Google sees the markup after rendering. |
| Schema.org validator | The Schema.org vocabulary itself: unknown types, unknown properties and value shapes, with no Google-specific rules. | A live URL or a pasted snippet, in JSON-LD, microdata or RDFa. | Types Google has no rich result for, such as DefinedTerm or HowTo, and markup aimed at consumers other than Google. |
The order that works: this tool while you build, the Schema.org validator if you use types outside Google’s rich-result list, and the Rich Results Test on the live URL before you call it done. It will not fetch your page, resolve image URLs, or test value types. A block that passes here and fails in Google is almost always a shape problem: an object expected where a string was given, or a date not in ISO 8601.
Who uses a schema markup validator
Three roles run this tool for three different reasons.
✓SEO and AEO leads
Run it on the template output for every page type before launch. The question is not whether the page has schema but whether the fields a citation is built from are all present and all true.
✓Developers
Paste the rendered output of your JSON-LD component, not the source. Most failures come from string interpolation: a product name with a quote in it, a null in a required field, a date serialised in the wrong format.
✓Agencies
Validate every client page type on the same rules so audits are comparable across accounts. The rules table on this page is the reference to hand a client when they ask why a page failed.
Valid structured data is the floor for AI visibility, not the ceiling. Once the markup passes, the next question is whether ChatGPT, Perplexity and Google’s AI answers actually cite those pages, and for which prompts. That is what the Asva AI platform measures.
Frequently asked questions
What does this schema markup validator check?+
Five things, in order: the input is not empty, the JSON parses, the root declares a Schema.org "@context", at least one entity has an "@type", and each entity of a rich-result type has the fields Google marks as required and recommended. Fifteen types are covered. Required misses are errors; recommended misses are warnings.
Is a JSON-LD validator the same as a schema markup validator?+
For most sites, yes. Schema markup can be written as JSON-LD, microdata or RDFa; JSON-LD is the format Google recommends and the one nearly every modern platform emits. A JSON-LD validator checks that one format, while a schema markup validator in the broad sense could read all three. This tool reads JSON-LD only.
Why is my valid JSON showing errors?+
Valid JSON can still be invalid structured data. The usual causes: no "@context" on the root object, no "@type", a type name in the wrong case such as "product", or a required field absent for the declared type, for example an Article with "title" instead of "headline". The error message names the type and the missing field, so fix those first and re-run.
Is this the same as Google’s Rich Results Test?+
No, and they are best used together. This tool checks pasted markup against the required and recommended fields Google documents, instantly and without uploading anything. Google’s Rich Results Test fetches and renders a live URL, reports eligibility for Google’s own rich-result features. Use this while you build; use Google’s on the published page.
Why does my markup pass here but fail in Google’s tool?+
This validator checks that a field is present, not that its value is the right shape. "offers": "1395 USD" passes here because "offers" exists, and fails in Google because Google expects an Offer object with price and priceCurrency. Dates written as "July 24, 2026" instead of "2026-07-24" behave the same way. Fix the shape and both tools agree.
Can I paste a full <script> tag?+
Yes. Paste the complete <script type="application/ld+json"> element straight from view-source and the validator extracts the JSON inside before parsing. A bare object, an array of objects, or a document with an "@graph" also work. Only the first script block in the paste is read, so validate multiple blocks one at a time.
Does the validator check nested entities like an Offer inside a Product?+
Partly. Nested types are detected and listed, so you can confirm the Offer, Brand or Person is there. The field checks run on entities at the root, in a root array, or inside "@graph"; an Offer nested under "offers" is not tested against its own price and priceCurrency rule. To check it fully, paste it on its own or put it in an "@graph".
Does it send my markup anywhere?+
No. Validation runs entirely in your browser and the text stays on your machine. That is deliberate: a lot of structured data describes products that have not launched, articles not yet published, or prices still under embargo. You can validate markup for a page that does not exist yet without it leaving your laptop.
Does valid schema markup guarantee a rich result or an AI citation?+
No. Valid markup makes a page eligible; it does not make it chosen. Google decides which eligible pages get a rich result, and has restricted FAQ and HowTo results since 2023. AI answer engines weigh the visible content, the source’s authority and the fit to the prompt. Validation removes the reasons a page can be skipped on a technicality; it does not replace the rest of the work.