A JSON-LD checker's extraction path determines what it actually reveals about your markup — script blocks, attribute pairs, parse errors, and profile warnings each surface through a different mechanism. Extraction-first checkers walk the parsed document locally, expanding JSON-LD containers into individual items while preserving @type values and visible properties. JSON-LD-only tools run JSON.parse against a single copied snippet, which is fast but blind to Microdata. Remote-fetch validators request the deployed URL through a headless browser and grade against feature-specific profiles, useful for final sign-off, but unable to audit templates that have not been deployed. The right path depends on whether you are reviewing a template, debugging one script block, or verifying a deployed page. The Structured Data Checker & Extractor uses an extraction-first path: it accepts pasted HTML, expands JSON-LD containers (single object, array, or @graph), and walks Microdata items while keeping nested values visibly nested.
What Extraction Actually Means in a JSON-LD Checker
Extraction is the act of turning whatever sits inside the document — script blocks, attribute pairs, or both — into a readable inventory of declared types and properties. It is not validation, scoring, or feature eligibility, and the difference matters when you compare tools. A tool that conflates extraction with grading will report "no problems found" the moment your JSON parses, even when the document is missing every property a particular search feature expects.
An extraction-first checker surfaces three separate buckets. The first is parse errors: malformed JSON-LD, broken containers, or HTML that the parser cannot walk. The second is the property inventory: every @type and property actually emitted by the document, normalised so a single object, an array, and an @graph node all appear as discrete items. The third is profile warnings: focused notes about properties the local rule set expected but did not find, attached to documented contracts only. Keeping these buckets separate is what lets you tell the difference between "the script tag has a syntax error" and "the script parses, but the Article object lacks datePublished."
This separation also matters for trust. A warning means the local profile did not find a property; it does not prove that a search engine will reject the page. Validity and eligibility are different questions, and any checker that fuses them into one score hides the evidence you need to decide what to fix first.
The Main Extraction Paths Compared
Most JSON-LD and structured-data checkers fall into four practical camps. The right one depends on what stage of work you are in, what privacy constraints apply to the source, and whether you also need Microdata or RDFa coverage.
| Path | What the tool sees | What it misses | Best stage |
|---|---|---|---|
| Paste full HTML locally | All script blocks plus every itemscope / itemprop / itemtype pair in the rendered template | Markup injected after load by client-side JavaScript | Template review before deployment |
| Paste a JSON-LD snippet only | One script block, parsed with JSON.parse | Microdata, RDFa, other script blocks in the same page | Debugging a single malformed script |
| Paste a rendered DOM export | What the browser produced after framework hydration | Markup the crawler receives if hydration differs from server response | Comparing client-rendered output to source |
| Remote URL fetch by the tool | Whatever the tool's crawler retrieves | Undeployed templates, private-network pages, markup behind auth | Post-deployment verification |
The paste-HTML path is the broadest extraction approach because it accepts the whole document and lets a single tool walk JSON-LD and Microdata together. Tools that fetch a URL or only accept a snippet narrow that view by design, which is useful when you want a focused result but limiting when the question is "what does this template actually emit?" For a deeper look at why fetch-based tools cannot always audit your page, the guide on whether a JSON-LD checker fetches or runs your webpage walks through the boundary.
Run a Paste-and-Parse Workflow With the Local Checker
The extraction-first approach is the fastest way to audit markup before deployment, because nothing leaves your browser. The Structured Data Checker & Extractor follows this workflow.
- Copy the delivered HTML source for the template you want to audit, or export a controlled rendered-DOM snapshot if a framework injects markup after load. The checker never fetches a URL or executes scripts from the paste.
- Paste the source into the input. The tool builds an isolated document fragment, so no script from the pasted HTML runs against the live page and no embedded resource is requested.
- Run the extraction. JSON-LD containers (single object, array, @graph) are expanded into individual items so each declared @type and property appears on its own row.
- Review the parse-error list separately. A malformed JSON block is reported on its own, so one broken script does not erase valid items found elsewhere in the same document.
- Walk the Microdata inventory. itemscope and itemtype pairs become top-level items, and itemprop values pulled from content attributes, links, dates and text content appear as bounded properties. Nested items remain visibly nested.
- Read the focused missing-property warnings. Each warning references a documented profile rule, so you can match it back to the search-feature documentation before deciding whether to change the template.
- Fix the source template, redeploy, and validate the live URL with the official tool for the search feature you actually target.
Input size and item counts are bounded so an accidental full-site dump cannot freeze the page, and no extracted value is rendered as live HTML — every property appears as plain text so the report itself cannot inject markup into the review screen.
JSON-LD and Microdata: What Each Path Surfaces
JSON-LD and Microdata describe the same kind of information through different mechanisms, and a checker that handles only one will silently miss half of what is on the page. Google's structured-data documentation recommends JSON-LD because it is generally easier to maintain, while still supporting Microdata and RDFa where they are documented. That means a tool limited to JSON-LD will leave Microdata unparsed, and a tool limited to Microdata will leave every script tag unread.
| Dimension | JSON-LD | Microdata |
|---|---|---|
| Where the data lives | Inside a script tag, anywhere in the document | Inline on ordinary HTML elements via itemprop |
| Failure mode | Whole script ignored if JSON is malformed | Individual property lost if attribute is wrong |
| Nested structures | @graph nodes, nested objects, arrays | Nested items via itemscope on inner elements |
| Typical review question | Did the template emit duplicate items in an @graph? | Did the wrong attribute leave a URL blank? |
When both paths are walked in the same tool, the comparison becomes visible: you can see whether JSON-LD claims an Article with headline X while Microdata marks up the surrounding wrapper as a NewsArticle with headline Y, and you can audit nested items without them being silently flattened into unrelated strings. The WHATWG Microdata specification defines how itemscope, itemtype, and itemprop combine, and a checker that follows that contract surfaces the same shape the browser would.
What Extraction Cannot Tell You About Your Page
A clean extraction result reveals what the pasted document contains, but it does not reveal how a search engine will treat that document. Validity and eligibility are different questions. A complete-looking object can still violate a search policy, disagree with the visible page, use an unsupported feature, or fail a deployment test. Conversely, Schema.org properties that are not part of a Google feature can still be meaningful to other consumers. This is why the checker separates parse errors, focused missing properties and informational observations rather than collapsing them into one grade.
Extraction also cannot tell you whether your markup will reach a crawler. If a framework injects structured data after load, the original server response, the rendered DOM and the crawler-visible output can all differ. The extraction-first workflow handles this by accepting either the delivered HTML source or a controlled DOM export, so you can paste each view in turn and compare what each one actually contains. No script from the pasted document runs during the check, which keeps the audit isolated from the live page.
Finally, local extraction does not simulate every consumer. The focused fixtures in the tool cover a valid JSON-LD object, an @graph, a top-level array, malformed JSON, a missing required property, multiple types, basic Microdata extraction and nested values. Negative cases include executable-looking pasted text, oversized source and unsupported structures. These checks protect deterministic parsing; they do not reproduce what Google, Bing, or a third-party consumer will do with the same markup. Treat the extracted inventory as evidence about the pasted document, then move to the official validator for the search feature you target.
Matching the Path to Your Source
The source you have available often dictates the approach more than preference. A CMS export is delivered HTML and pairs naturally with the paste-HTML workflow. A framework that hydrates on the client may produce three different views — the original server response, the rendered DOM, and what the crawler actually receives — and each one can be pasted separately for comparison. A snippet copied from View Source is fine for debugging one script block, but it is the wrong tool for asking whether the template emits a required property, because it cannot see the rest of the page.
If you are deciding which extraction path to standardise on for ongoing audits, the trade-off is usually between coverage and isolation. Remote-fetch tools cover more of the live site at once, but they cannot audit templates that have not been deployed, they hit cross-origin failures on private environments, and they conflate parsing with feature policy. Paste-based extraction narrows the view to one document at a time but gives you a transparent, evidence-linked review of what that document contains, with no ambiguity about what the tool actually parsed.
RDFa is worth calling out separately. The Structured Data Checker & Extractor extracts JSON-LD and Microdata only. RDFa is outside the current product boundary and is never counted as absent or invalid structured data. If your template relies on RDFa, the local checker will not surface it; you will need a different tool or the official validator for the search feature you target.
From Extraction to Official Validation
Local extraction answers concrete questions about the markup you have in front of you: is the intended type present, did a template emit duplicate items, is a required field missing from one variant, does a JSON-LD block fail to parse, does Microdata expose a blank URL because the wrong attribute was used. Those answers are the input to template fixes, not the output of a search-engine decision.
After making a change, validate the public URL with the official validator for the search feature you target. For Google features, the Rich Results Test and Search Console enhancement reports cover the deployment and indexing side that no local checker can see. Search engines decide whether and when enhanced presentation appears, so the right way to use extraction paths is to pick the one that gives you transparent evidence about the pasted document, then move to official testing once the template is fixed. Required-property guidance is not a substitute for content review: markup should represent content users can actually see, and fewer complete and truthful properties are preferable to a large object filled with generic or fabricated values.