A local JSON-LD checker that uses a detached template pattern never fetches your webpage, never executes its scripts, and never sends your source anywhere. The Structured Data Checker & Extractor runs entirely inside your browser. You paste the HTML you already have, and the tool parses that text inside an isolated document fragment. The fragment is detached from the live page, so no script inside the pasted markup can reach your cookies, your session, or your network. The tool does not follow links, load images, submit forms, or evaluate embedded JavaScript. It also does not request a URL from a remote server, which means there are no cross-origin failures, no private-network calls, and no risk of auditing markup that differs from what a search crawler actually receives. Everything you see in the result is an inventory of the text you pasted, not a promise about how a search engine will treat your page.
That boundary matters for two practical reasons. First, a live fetch can return a different document than the one you wrote into your template, because frameworks, edge workers, and personalization layers inject markup after the initial response. Second, any tool that runs your scripts could observe behavior or data you did not intend to share. A paste-only workflow keeps the audit focused on the source you control and removes both variables at once.
What "fetch" or "run" would actually do to your page
A tool that fetches a URL issues an HTTP request to a server, receives the response body the server sends, and parses that body. A tool that runs a page does more: it loads images and stylesheets, executes JavaScript, fires events, follows redirects, and may submit forms or trigger analytics. For a structured-data audit, both behaviors create problems that have nothing to do with markup quality.
The table below summarizes the practical difference between a live-fetch or page-run tool and the paste-only approach of the Structured Data Checker & Extractor.
| Behavior during a structured-data audit | Live-fetch or page-run tool | Structured Data Checker & Extractor |
|---|---|---|
| Sends an HTTP request to your server | Yes | No |
| Executes scripts inside the document | Yes | No |
| Loads images, stylesheets, and other resources | Yes | No |
| Can submit forms or trigger analytics beacons | Yes | No |
| Audits markup that may differ from the crawler-visible HTML | Yes | No, by design |
| Parses JSON-LD and Microdata from a document | Yes | Yes |
| Reports focused missing-property warnings against documented profiles | Sometimes | Yes |
A live fetch can mislead you. A page that returns one document for an anonymous request and a different document for an authenticated user will give the checker whichever the server decided to send. Crawler-visible HTML, rendered DOM, and the original response often diverge in subtle ways, especially on sites that rely on client-side rendering. If your audit runs against the wrong variant, you may add fields that never actually reach the index.
A tool that runs your page opens a wider set of risks. Pasted HTML can include tracking pixels, third-party scripts, and analytics beacons. Even a sandboxed iframe can issue network requests from inside the checker. Those that reach internal endpoints can leak information about your staging environment, your CMS, or your visitor identifiers. A paste-only tool treats the document as inert text, so none of those side effects can occur.
How a detached browser template keeps parsing local
The extraction engine uses a detached template pattern. When you paste HTML, the parser creates an isolated document fragment inside your browser tab. That fragment is not attached to the live DOM, so any script tag inside the pasted text is parsed as a script element but never executed. The fragment exists only long enough for the parser to walk its nodes, collect JSON-LD blocks, and read Microdata attributes.
JSON-LD lives inside <script type="application/ld+json"> elements. The checker reads the text content of those elements, runs a JSON parser, and expands the result into individual items. A single object becomes one item. An array becomes a list of items. An @graph node is expanded into the items it contains, each preserving its declared @type and visible properties. If one script block fails to parse, the error is reported separately so valid items elsewhere in the same document are not erased.
Microdata lives inside ordinary HTML using itemscope, itemtype, and itemprop attributes. The checker walks the parsed fragment and builds a bounded property view for each top-level item. Values exposed through content attributes, links, media source attributes, date values, and text content are all read. Nested items stay nested in the display instead of being silently flattened into unrelated strings, which makes it easier to spot when a template meant to emit a Recipe with nested NutritionInformation lost its inner structure.
Input size and item counts are bounded so an accidental full-site dump cannot freeze the tab. The detached fragment is also short-lived: once parsing finishes, the fragment is discarded. Nothing in your pasted document reaches the network, the parent page, or the Lizely server.
Review JSON-LD and Microdata without exposing source
- Open the Structured Data Checker & Extractor in your browser. No account, login, or upload step is required.
- Paste the delivered HTML source — the response body your server actually sends — into the input area. If your framework injects markup after load, paste a controlled rendered-DOM export alongside the original response so you can compare them.
- Run extraction. The tool walks the detached fragment, finds every JSON-LD block and Microdata item, and presents them as an inventory rather than a score.
- Read the parse-error section first. A malformed JSON block is reported on its own line; fix those before trusting the rest of the inventory.
- Walk each extracted item. Confirm that the declared @type matches the page's visible content, that required properties are present, and that no duplicate items were emitted by your template.
- Read the focused missing-property warnings. A warning means a supported profile did not find a property in your pasted markup; it does not prove that a search engine will reject the page.
- Inspect nested values. Microdata nesting should mirror the relationship you intended, and JSON-LD @graph nodes should still expose their inner types.
For more on the upload-versus-paste distinction, see Can I Use a JSON-LD Checker Without Uploading a File? — it covers the same local-parsing boundary from a different angle.
Validate the deployed URL with official tooling
A local checker reports facts about the document you pasted. Eligibility for any specific search feature is a separate question, and only the search engine itself can answer it. After you fix your template based on the local inventory, deploy the change and run the public URL through the appropriate official validator.
For types that target a Google feature, Google's structured data introduction lists which formats and properties each feature requires. The Rich Results Test runs the deployed URL, executes the page, and reports whether a specific rich result feature applies. Search Console's enhancement reports confirm whether recrawling picked up the change and whether Google considers the markup eligible.
For Microdata specifically, the WHATWG HTML Microdata specification defines how itemscope, itemtype, and itemprop interact. When the local checker reports a blank Microdata URL, the cause is almost always the wrong attribute on the wrong element — the spec is the fastest way to confirm what the parser should have seen.
Test the actual template across representative records. A single product page can validate while a category page on the same site emits duplicates, and a recipe template can pass on one dish while failing on another. Local extraction is fast enough to repeat across variants before you ask Google to recrawl.
Limits and edge cases worth knowing
The checker 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 site relies on RDFa, a clean local result will not reflect whether your markup is correct; you will need a different validator for that vocabulary.
Required-property guidance is not a substitute for content review. Markup should represent content a user can actually see, and it should use specific, accurate values. Adding fields merely to silence a warning can make the implementation less trustworthy. Fewer complete and truthful properties are usually preferable to a large object filled with generic or fabricated values, because search products publish policies that look past the markup and at the visible page.
The detached-template parser does not simulate every consumer. It reports parse errors and focused property gaps against documented profiles; it does not run the page the way a browser does, and it cannot tell you whether a particular search engine will index, rank, or enhance your result. Use the local inventory as transparent preflight, then verify the deployed response with the official tools for the search feature you actually target.