Structured Data Validator
Inspect JSON-LD graphs for syntax, contexts, types, IDs, references, duplicates, and implementation warnings.
Page context helps interpret relative @id and common URL properties. The page itself is not fetched.
Accepts one raw JSON-LD value or HTML containing one or more application/ld+json script blocks.
JSON-LD documents, graph nodes, @type / @id relationships, duplicate source keys, and implementation findings will appear here.
“Valid Structured Data” Is Really Several Different Questions
First, the text must be valid JSON when you use JSON-LD. Second, it must make sense as JSON-LD: contexts, IDs, types, graphs and references have JSON-LD semantics. Third, the terms need to belong to the vocabulary you intend to use, such as Schema.org. Finally, a consumer such as Google Search can impose feature-specific required properties and quality rules.
Passing one layer does not prove the next. The browser review focuses on the first two layers and selected implementation signals. It refuses to turn a structural JSON-LD check into a fake “rich result valid” badge.
@context Is What Makes “Article” and “headline” More Than Private JSON Keys
Ordinary JSON does not know what Article, headline, or author means. JSON-LD context information maps compact terms to IRIs so different systems can interpret them as linked-data vocabulary rather than application keys invented by one site.
Schema.org markup commonly uses "@context": "https://schema.org". JSON-LD also supports local context objects, arrays of contexts, vocabulary mappings and other advanced forms. This browser does not download remote context documents, so it reports what is declared without pretending to perform full JSON-LD expansion.
@id Is Graph Identity, Not Just Another “URL Field”
Two node objects can intentionally use the same @id because they are making statements about the same graph node. A WebPage might refer to an Organization using only { "@id": "https://example.com/#organization" }, while another node in the graph supplies that organization's name, logo and URL.
For that reason the checker marks repeated IDs as a review note, not an automatic duplicate-entity error. It also labels objects that contain only @id as references rather than pretending each reference is a fully described entity.
Duplicate JSON Keys Can Disappear Before a JSON-LD Library Ever Sees Them
{
"@type": "Article",
"headline": "First headline",
"headline": "Second headline"
}JavaScript's JSON parser produces one object property for that repeated name, effectively hiding the earlier source value. Other software can handle duplicate names differently. The source is scanned the source before parsing and reports repeated member names so the markup can be fixed instead of relying on overwrite behavior.
@graph Helps Connect Page Entities, but It Is Not a Requirement for “Good JSON-LD”
A page can use one simple top-level Article object and be perfectly reasonable. @graph becomes helpful when a page describes several named nodes—a WebSite, Organization, WebPage, Person, Article, BreadcrumbList or other related objects—and you want their @id references to make those relationships explicit.
The checker understands graph arrays and graph objects but does not penalize markup simply because it chose a simpler non-graph shape.
Multiple application/ld+json Blocks Are Not Automatically Duplicate Markup
A template may emit Organization markup in one component and page-specific Article markup in another. Google can read JSON-LD embedded in page markup, and multiple script blocks can represent complementary data.
The real problem is accidental duplication: two layout systems describing the same article with conflicting headlines, IDs or dates. The report shows the number of blocks and repeated IDs so you can review the graph instead of enforcing “exactly one script” as an invented rule.
Schema.org Vocabulary Is Larger Than Google's Rich-Result Feature Set
A type or property can be legitimate Schema.org vocabulary without powering a special Google Search appearance. Conversely, a Google feature can require a specific subset of Schema.org properties and additional content/quality conditions.
For Google behavior, Google explicitly tells publishers to use its feature documentation as definitive rather than assuming every Schema.org possibility is supported in Search. This is why the tool does not maintain a stale hard-coded list of “Google-valid types.”
Markup Has to Describe the Page the User Actually Gets
Google's structured-data guidance says the markup on a page should describe that page's content and should not invent information that is invisible or misleading to users. A browser JSON-LD parser cannot judge whether a five-star rating, price, event date or author name is truthful.
Technical validation therefore cannot replace editorial accuracy. Compare important structured properties with the visible rendered page, especially when data is generated from separate CMS fields or APIs.
Test the Rendered Production Page, Not Only the JSON-LD Snippet in Your Editor
Framework hydration, tag managers, CMS plugins, personalization and deployment templates can remove, duplicate or change JSON-LD after the component you inspected locally. Google supports JSON-LD and recommends it in many implementations, but eligibility belongs to the final page Google can process.
After this structural pass, use Google's Rich Results Test for supported Search features and Search Console after deployment.
Three References Answer Three Different Questions
Defines JSON-LD keywords, contexts, node identifiers, graphs and the linked-data processing model.
Defines the vocabulary of types and properties commonly used in web structured data.
Defines Google Search formats, feature documentation, required/recommended properties and rich-result guidance.