Extraction-first structured data checkers and plain JSON-LD validators answer two different questions, and choosing between them depends on whether you need evidence about the markup already present in your document or confirmation that one specific search consumer accepts it. A JSON-LD syntax checker answers "is this block valid JSON and does it describe a known type?" while an extractor answers "what structured data actually lives in this HTML, item by item?" A validator that targets a single search feature will tell you only whether Google currently accepts the type for that feature. An extractor that does not fetch or execute the page instead gives you a readable inventory of every JSON-LD block, every Microdata item, every declared type, and every visible property. The two answers overlap when everything is simple, and diverge sharply once templates, multiple types, third-party injection, or unfamiliar Schema.org types enter the picture. The Structured Data Checker & Extractor sits firmly on the extraction side of that line, and the rest of this article walks through when that posture is the right one.
Extraction vs Validation: Different Jobs, Different Evidence
The terms "JSON-LD checker" and "structured data extractor" get used interchangeably, even though they describe tools with very different contracts. A JSON-LD syntax checker accepts a block, runs JSON.parse, and reports whether the script tag contains well-formed JSON that resolves to a recognizable Schema.org type. A structured data extractor accepts a document, walks every script tag and every HTML node, and reports what is actually there.
Schema.org defines a broad vocabulary; search products publish narrower required and recommended property sets for particular rich experiences. Extraction can stay general because describing an object is easier than scoring one. Validation against a single consumer's profile, by contrast, must be explicit and inspectable because every missing property could trigger a warning. When you paste the same document into each kind of tool, you can end up with a green checkmark on the validator and a long list of unresolved issues on the extractor, or the reverse, and neither contradiction means the tool is broken. They are answering different questions about the same source.
For most production work, the useful question is: do I need an inventory of what exists, or do I need confirmation that one product accepts it? That single fork separates the cases below.
Signs You Need an Extractor Instead of a Plain JSON-LD Check
A few recurring situations tip the decision toward extraction. The first is template-driven content, where a single source emits dozens or hundreds of records with small variations; a syntax check on one snippet says nothing about the next one. The second is mixed format content: a page that ships both JSON-LD and Microdata, sometimes inherited from a CMS theme, sometimes added by a plugin, and sometimes edited by hand. A pure JSON-LD checker will quietly miss the Microdata half. The third is unknown or rarely used Schema.org types that the search feature you care about does not document; a validator can refuse to grade them at all, while an extractor will still list every property you supplied.
The fourth is pre-flight debugging after a regression. A change to a template, a CMS upgrade, or a new structured-data plugin can quietly duplicate blocks, drop a required field from one variant, or produce a JSON-LD script that no longer parses. A validator run on a single rendered page may not surface that pattern because it only sees one of the duplicates. An extractor surfaces every block in the document and reports which ones failed to parse separately from the rest.
The fifth is any workflow where the markup must not leave your machine: internal documentation, draft staging servers behind a firewall, or pages that require authentication. Since the Structured Data Checker & Extractor never fetches, executes, or sends the source, you can paste the delivered HTML directly. For related decision criteria specific to JSON-LD, the guide on Choosing a Structured Data Checker Approach for JSON-LD walks through the same trade-off from a different angle.
Signs a Validator Is Enough on Its Own
The opposite case is also real. A focused JSON-LD check makes sense when the type is one that Google or another consumer has documented, the template is stable, the rendered page is reachable from the public internet, and you are checking whether the specific feature you target will accept the page. Once those four conditions hold, a validator gives you a tighter signal than an extractor can, because it is asking the question you actually care about.
Validators are also the right tool after a successful extraction. If your extractor reports a complete inventory with no parse errors and no profile warnings for the type you target, the next step is to confirm the deployed URL with the consumer that will read it. Per the Google Search Central introduction to structured data, syntax validity and search eligibility are separate questions, and an "extracted cleanly" result does not prove a rich result is coming. The validator exists for exactly that final confirmation.
| Situation | Better fit | Why |
|---|---|---|
| Template with many variants, one snippet pasted | Extractor | Inventory reflects only the snippet pasted; inspect each template variant separately |
| Mixed JSON-LD and Microdata on one page | Extractor | A JSON-LD-only check silently misses the Microdata half |
| Uncommon or custom Schema.org type | Extractor | Validator may not grade what it does not document |
| Stable, documented type on a public URL | Validator | Direct answer from the consumer you target |
| Post-deployment sign-off for one feature | Validator | Confirms eligibility, not just syntax |
How to Run the Structured Data Checker & Extractor
The workflow is intentionally narrow so that the evidence stays tied to the document you actually pasted.
- Export the delivered HTML source or a controlled rendered-DOM export from the page or template you want to inspect. The checker never fetches URLs, so you control exactly what goes in.
- Paste the markup into the Structured Data Checker & Extractor input.
- Run extraction, then review JSON-LD parse errors, Microdata items, declared types, properties, and focused missing-property warnings separately.
- Compare the extracted items against what the template is meant to emit. Note any duplicate types, empty URL fields, or properties that disappeared after a recent change.
- Fix the source template rather than the extracted output. The inventory is evidence; the source is what gets shipped.
- Once the template is fixed, validate the deployed URL with the official Rich Results Test for the search feature you target. Local extraction never replaces that final step.
Reading the Extracted Inventory
The output is intentionally split so that a single broken script cannot mask a healthy one. A malformed JSON-LD block is reported on its own; valid items found elsewhere in the same document remain visible. JSON-LD containers expand into individual items while preserving declared @type values and visible properties, whether the source was a single object, an array, or an @graph of several nodes.
Microdata is read through itemscope, itemtype, and itemprop on regular HTML, and the bounded property view covers values exposed through content attributes, links, media source attributes, date values, and text content. Nested items remain nested rather than being silently flattened into unrelated strings. If the extractor shows a Microdata URL as blank, that usually points to the wrong attribute on the element rather than to a missing field.
Profile warnings carry a specific meaning: the local profile did not find a property. A warning is not the same as a rejection, and a clean result is not a guarantee of a rich result. Treat the inventory as a list of concrete questions to answer, such as "is the intended type present?", "did the template emit duplicate items?", "is a required field missing from one variant?", and "does any JSON-LD block fail to parse?" Those questions are the ones the extractor can answer; everything else belongs to the deployed URL and the search engine.
Pairing Local Extraction with the Official Validator
A practical workflow uses both tools in sequence. Start with extraction to confirm that the markup you expect is the markup you ship. Resolve parse errors first, because nothing downstream of a broken script can be trusted. Then review profile warnings against the linked documentation, fix the template, redeploy, and finish with the official validator for the search feature you target.
Two limits to keep in mind. First, the checker supports JSON-LD and Microdata only; RDFa is outside the current product boundary and is never counted as absent or invalid structured data. If your page relies on RDFa, the inventory will not reflect that portion of the markup, and you should not interpret a clean JSON-LD result as a full coverage audit. Second, fewer complete and truthful properties are preferable to a large object padded with generic or fabricated values; required-property guidance is not a substitute for content review, and markup should represent content users can actually see.
The extractor does not simulate every consumer, does not execute scripts from the pasted document, and does not follow links or submit forms. Input size and item counts are bounded so an accidental full-site dump cannot freeze the page, and parsed nodes live inside a detached template fragment outside the live page. Use the tool as a transparent preflight before official testing: paste authorized HTML, inspect every extracted item, resolve parse errors first, review profile warnings against the linked documentation, and then verify the deployed response. The output is evidence about the pasted document, not a promise about search appearance.