Does this validate full schema.org compliance?

No. It checks JSON parsing plus top-level @context and @type presence. Use type-specific schema tests or Google Rich Results Test for required properties and rich-result eligibility.

Can I paste a full HTML page?

Yes. If the input contains HTML, the validator extracts application/ld+json script blocks and checks each one.

Can I paste raw JSON-LD without a script tag?

Yes. Raw JSON-LD objects and arrays are parsed directly when the input does not look like HTML.

Do you fetch schema.org contexts or my page URL?

No. The validator does not make network calls. It only parses the snippet already in your browser.

Is valid JSON-LD enough for rich results?

No. Search engines also consider schema type, required properties, visible page content, policies, crawlability, canonicalization, and quality signals. Treat this as a first-pass structural check.

Should schema URLs match my canonical and Open Graph URLs?

Usually yes. Keep @id, url, image, logo, and breadcrumb URLs aligned with canonical/hreflang, Open Graph, sitemap.xml, and production asset URLs unless you intentionally need a different entity URL.

Why test rendered HTML instead of source code?

Frameworks, CMS plugins, ecommerce themes, and tag managers can add, remove, duplicate, or override JSON-LD. Rendered HTML is closer to what crawlers and rich-result tools inspect.

Is my structured data stored?

No. Pasted HTML and JSON-LD are not uploaded, logged, stored, or shared.

web validator

JSON-LD SEO Validator & Rich Result Schema Checker

Validate rendered JSON-LD structured data for schema.org syntax, rich-result readiness, visible-content alignment, and crawlable schema blocks before publishing.

Results

Paste input and validate locally.

Status: Ready when you validate.
Details: Ready when you validate.
Blocks found: Ready when you validate.
Invalid blocks: Ready when you validate.
Types: Ready when you validate.

How to use this validator

Copy rendered HTML source, deployed-preview output, crawler-exported HTML, or the exact JSON-LD script block from the page.
Paste it into the validator and run the local check.
Review the number of blocks found, invalid block count, and detected schema types.
Fix malformed JSON, missing @context, missing @type, invisible/stale template output, or schema values that disagree with visible page content before publishing.
For final search eligibility, also test the live canonical URL with Google Rich Results Test or Search Console because this page is a structural validator only.

Rules & checks

Extracts <script type="application/ld+json"> blocks from pasted HTML, or parses raw JSON-LD when no HTML tags are present.

Supports a single JSON-LD object or an array of objects and reports the schema @type values found for launch QA.

Requires each parsed JSON-LD object to include string @context and @type fields.

Flags malformed JSON, empty script tags, non-object blocks, and blocks missing required top-level fields.

Validates rendered markup rather than source components because CMS plugins, Next.js metadata, ecommerce themes, and tag managers can change final schema output.

Runs locally in the browser; it does not fetch remote contexts, call Google tools, crawl canonical URLs, or guarantee rich-result eligibility.

Inputs explained

Rendered HTML or JSON-LD schema
Paste a rendered page head/body containing application/ld+json scripts, view-source output, deployed preview HTML, crawler export, or raw JSON-LD directly. Rendered HTML is best for checking what crawlers can actually see after your CMS, Next.js metadata, Shopify theme, WordPress plugin, or framework output is generated.

When to use it

QA Article, FAQPage, Product, Organization, LocalBusiness, BreadcrumbList, WebSite, and SoftwareApplication schema snippets before launch.
Check structured data generated by Next.js, WordPress, Shopify, Webflow, Astro, or a headless CMS template.
Review contributed schema snippets from clients or editors without uploading draft page HTML.
Debug why a rendered page has no JSON-LD blocks even though the template source appears to define schema.
Check template-level schema output after CMS migrations, Next.js metadata changes, product imports, or programmatic page generation.
Pair structured data QA with Open Graph, canonical/hreflang, HTML meta, viewport, meta robots, sitemap.xml, and URL checks during an SEO launch pass.

Common errors

Missing @context or @type on a structured data object.
Trailing commas, smart quotes, comments, or unescaped line breaks that make the JSON invalid.
Pasting component source instead of rendered application/ld+json script output.
Using FAQ, Product, Review, LocalBusiness, or Article schema that does not match visible page content.
Schema @id, url, image, breadcrumb, or author values drifting from canonical URLs, Open Graph URLs, sitemap entries, or production assets.
Assuming valid JSON-LD syntax guarantees Google rich-result eligibility for a specific schema type.
Only checking the homepage while article, product, local business, SaaS, FAQ, review, or breadcrumb templates output different schema blocks.

Limitations

Checks syntax and top-level @context/@type presence only; it does not validate every schema.org property for each type.
Does not fetch remote contexts, crawl linked pages, resolve @id graphs, compare schema to visible DOM, or verify live URL indexability.
Does not guarantee Google, Bing, or social/search platforms will show a rich result.
Does not validate every required or recommended property for Article, Product, Review, FAQPage, LocalBusiness, or other rich-result-specific types.
Does not compare structured data against visible page content; mismatched or spammy schema can still be invalid for search policies.

Tips

Validate the rendered HTML, not just the source component, because search engines see generated output rather than your framework code.
Use https://schema.org as the standard @context unless you intentionally need another context.
Keep schema honest: only mark up FAQs, reviews, products, prices, authors, ratings, breadcrumbs, and local details that are visible and accurate on the page.
Keep @id, url, image, logo, and breadcrumb URLs aligned with canonical/hreflang, Open Graph, sitemap.xml, and production asset URLs.
Prettify the JSON-LD first if a large script is hard to read, then re-check the exact minified output that will be published.
After this structural pass, use a live URL test for type-specific rich-result requirements, canonical crawlability, Search Console enhancements, and Google-specific warnings.

Examples

Valid Article structured data

<script type="application/ld+json">{"@context":"https://schema.org","@type":"Article","headline":"Example"}</script>
Result: valid JSON-LD, 1 block found, type Article.

Multiple schema objects

[{"@context":"https://schema.org","@type":"Organization"},{"@context":"https://schema.org","@type":"WebSite"}]
Result: both objects are checked and the Organization, WebSite types are listed.

Missing @type

{"@context":"https://schema.org","headline":"Example"}
Result: invalid because the top-level @type field is missing.

Broken JSON in a script tag

<script type="application/ld+json">{"@context":"https://schema.org",}</script>
Result: parse error counted as an invalid JSON-LD block.

Deep dive

JSON-LD is the structured-data layer that can help eligible pages qualify for rich-result understanding when schema matches the visible content and the canonical URL is crawlable.

Paste rendered HTML to confirm application/ld+json scripts are present, parseable, crawler-visible, and carrying the expected Article, Product, Organization, LocalBusiness, FAQPage, BreadcrumbList, WebSite, or SoftwareApplication types before you publish or request indexing.

Use it after Open Graph/share-card QA to catch schema regressions from CMS plugins, Next.js metadata, Shopify themes, headless templates, and generated pages before Search Console or rich-result tools see the live URL.

The tool is intentionally private and browser-local, making it safe for draft content, staging HTML, unreleased product pages, or client schema snippets that should not be uploaded to a third-party service.

FAQs

Does this validate full schema.org compliance?: No. It checks JSON parsing plus top-level @context and @type presence. Use type-specific schema tests or Google Rich Results Test for required properties and rich-result eligibility.
Can I paste a full HTML page?: Yes. If the input contains HTML, the validator extracts application/ld+json script blocks and checks each one.
Can I paste raw JSON-LD without a script tag?: Yes. Raw JSON-LD objects and arrays are parsed directly when the input does not look like HTML.
Do you fetch schema.org contexts or my page URL?: No. The validator does not make network calls. It only parses the snippet already in your browser.
Is valid JSON-LD enough for rich results?: No. Search engines also consider schema type, required properties, visible page content, policies, crawlability, canonicalization, and quality signals. Treat this as a first-pass structural check.
Should schema URLs match my canonical and Open Graph URLs?: Usually yes. Keep @id, url, image, logo, and breadcrumb URLs aligned with canonical/hreflang, Open Graph, sitemap.xml, and production asset URLs unless you intentionally need a different entity URL.
Why test rendered HTML instead of source code?: Frameworks, CMS plugins, ecommerce themes, and tag managers can add, remove, duplicate, or override JSON-LD. Rendered HTML is closer to what crawlers and rich-result tools inspect.
Is my structured data stored?: No. Pasted HTML and JSON-LD are not uploaded, logged, stored, or shared.

Related validators

web

HTML Meta SEO Validator

Validate rendered HTML document basics—charset, html lang, language targeting, and launch-readiness signals that support crawl, accessibility, and snippet QA.

JSON-LD validation runs entirely in your browser. Pasted HTML, draft article schema, product data, local business details, staging URLs, and client snippets are not uploaded, fetched, logged, stored, or sent to a server.

Structural JSON-LD validation only. Passing here does not prove full schema.org conformance, visible-content alignment, search-policy compliance, or rich-result eligibility.