Does valid structured data guarantee rich results?

No. Validity is necessary but not sufficient — Google decides eligibility based on feature-specific requirements, content quality and site-level signals, and may show nothing even for perfect markup.

JSON-LD, Microdata or RDFa?

JSON-LD. Google recommends it, and because it lives in a script block rather than being interleaved with markup, a redesign cannot accidentally break it.

Can I mark up content that is not visible?

No. Structured data must describe content users can actually see on the page. Marking up hidden or absent content violates Google's spam policies and risks a manual action.

Why does my FAQ markup not produce a rich result?

FAQ rich results are now heavily restricted to authoritative government and health sites. Valid FAQPage markup remains useful for machine understanding, but the visual treatment is no longer widely granted.

Developer🌐 YAS server-sideAPI availableintermediate

JSON-LD Validator

Validates JSON-LD structured data — the format used for rich results in search engines.

Processed by YAS · not stored

Ready to runInstant execution

All tools →

JSON-LD

Loading tool…

What does this tool do?

Validates JSON-LD structured data — the format used for rich results in search engines.

Why would I use it?

You added schema.org markup and want to confirm it is valid JSON-LD.
Google is not showing rich results and you suspect structured data.
You want to check @context and @type usage.

Real-life example

Input

{"@context":"https://schema.org","@type":"Product","name":"YAS"}

Output

Valid JSON-LD ✓

It validates the JSON-LD syntax and required fields.

Input → Process → Output → Next

Input: Paste JSON-LD (usually inside a <script type="application/ld+json"> tag).
Process: YAS parses it as JSON and validates JSON-LD structure.
Output: Valid, or structured errors about context/type/fields.
Next action: Fix errors, then re-validate with Google's Rich Results Test.

Common mistakes

Missing @context.
Using an unknown @type or property.
Pasting the whole <script> tag instead of the JSON inside it.

What the result means

Valid means search engines can parse the graph; it does not guarantee rich-result eligibility.

Privacy & security

Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.

API

Endpoint

POST https://yas.sh/api/v1/tools/json-ld-validator

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/json-ld-validator" \
  -H "Content-Type: application/json" \
  -d '{"input":"{\"@context\":\"https://schema.org\",\"@type\":\"Article\"}"}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/json-ld-validator", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "input": "{\"@context\":\"https://schema.org\",\"@type\":\"Article\"}"
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/json-ld-validator", json={"input":"{\"@context\":\"https://schema.org\",\"@type\":\"Article\"}"})
data = r.json()

Field	Type	Required	Description
input	string	Yes	JSON-LD text

Success response

{ "valid": true, "types": ["Article"], "errors": [], "warnings": [...] }

Validate JSON-LD structured data (context, type).

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How JSON-LD Validator works

Validation happens in two layers. First, the JSON-LD must be syntactically valid JSON and structurally valid linked data: an @context establishing vocabulary, an @type naming the entity, and properties resolvable against that vocabulary. Second, for search features, the markup must satisfy Google's requirements for the specific type — which properties are required, which are recommended, and what value formats are accepted.

The distinction matters because valid JSON-LD is routinely ineligible for rich results. A Product missing offers, a Recipe without recipeIngredient, or a FAQPage whose questions do not appear in the visible page all parse perfectly while failing the feature requirements. Google additionally requires that structured data describe content actually visible to users — markup describing content that is not on the page is a spam policy violation, not a technical error.

When to use it: real-world scenarios

Preparing for rich results

Product, Recipe, Event, FAQ and HowTo each have distinct required properties. Validating before deployment is faster than waiting for Search Console to report the gap weeks later.

Debugging a lost rich result

Rich results disappear after a template change that dropped a property. Comparing the emitted markup against requirements localises it immediately.

Validating dynamically generated markup

Structured data assembled from a CMS can silently emit null values or empty arrays when a field is unset, which invalidates the block.

Checking a migration to JSON-LD

Moving from Microdata or RDFa to JSON-LD is a good moment to verify nothing was dropped in translation.

Pro tips

Never mark up content that is not visible on the page. Google treats that as spam, and the penalty is worse than having no structured data.
Use @id to connect entities across a site — one Organization node referenced from every page is cleaner than repeating the whole entity.
Prefer JSON-LD in a script tag over Microdata: it is separated from markup, so redesigns do not break it.
Validating syntax is not the same as testing eligibility. Use Google's Rich Results Test for the feature-specific verdict.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

Schema.org vocabulary is checked, but Google's per-feature requirements evolve and are not fully modelled.
Passing validation does not guarantee a rich result — eligibility also depends on content quality and site-level signals.
Markup injected by client-side JavaScript is not evaluated here.
Remote @context documents are not fetched, so a custom context cannot be fully resolved.

Frequently asked questions

Does valid structured data guarantee rich results?: No. Validity is necessary but not sufficient — Google decides eligibility based on feature-specific requirements, content quality and site-level signals, and may show nothing even for perfect markup.
JSON-LD, Microdata or RDFa?: JSON-LD. Google recommends it, and because it lives in a script block rather than being interleaved with markup, a redesign cannot accidentally break it.
Can I mark up content that is not visible?: No. Structured data must describe content users can actually see on the page. Marking up hidden or absent content violates Google's spam policies and risks a manual action.
Why does my FAQ markup not produce a rich result?: FAQ rich results are now heavily restricted to authoritative government and health sites. Valid FAQPage markup remains useful for machine understanding, but the visual treatment is no longer widely granted.

Related tools

JSON Validator Open Graph Preview