AAAnow, 25 years of innovation
JSON-LD SCHEMA VALIDATOR

The JSON-LD Schema Validator:
what valid actually means

The JSON-LD Schema Validator is a standalone product that tests structured data in code, HTML and live web pages. Use a URL, pasted HTML, pasted JSON-LD or a supported local text file. For a URL, it examines both the original response and a clean browser-rendered document.

DOCUMENT ID TOOL/2026/JSV/0001
PUBLISHED 23 August 2026
READ TIME 6 min
ADDRESS aaanow.ai/json-validator (live End Sept 2026)

That distinction matters because “valid” has several meanings in structured data. Correct JSON can still fail during JSON-LD processing, while a sound graph can use an unknown Schema.org term. Schema.org conformance can also coexist with a missing property required for a particular Google Search feature.

The validator reports those outcomes separately, so a narrow consumer requirement never masquerades as a universal failure.

For business users, the result begins with the practical issue: what failed, what consequence it carries, where ownership lies and what happens next (pass or fail) with technical evidence remains immediately available rather than hidden behind a pass score.

The governing sources remain explicit throughout the result. JSON findings trace to IETF standards; JSON-LD processing follows the W3C Recommendations; vocabulary evaluation uses Schema.org release 30.0; and consumer findings use current, published Google Search requirements. HTTP, crawl, rendering and visible-page evidence appear as a separate page layer. Advice written by the product is labelled as advice and cannot alter a standards result.

Each finding carries the authority, primary source, rule-bundle version, affected location, observed evidence, expected condition, consequence and correction route. A reader can begin with the business summary, open the affected entity and property, then reach the original script block and source line. That path preserves the connection between compact JSON-LD and its expanded graph meaning.

URL work runs within controlled network and browser boundaries. Submitted material and active results are ephemeral by default, while ordinary service logs exclude complete source bodies and unbounded literal values. Versioned rules keep each result tied to its recorded validation environment.

01What the product does

1 connected evaluation covers work that is often split across unrelated tools. It checks whether the source is interoperable JSON, processes it under JSON-LD 1.1, builds the resulting graph, resolves Schema.org terms and applies the relevant published consumer requirements. When page evidence exists, the same result also records what the public response and rendered document reveal.

The output is diagnostic rather than a decorative score. It shows whether processing completed, which entities were found, where a failure began and which correction preserves the intended meaning.

02How structured data is submitted

  • URL. Retrieves the response through controlled network handling, extracts raw JSON-LD, renders the page in an isolated browser and compares both views.
  • Pasted HTML. Extracts JSON-LD script blocks, preserves their document order and validates the merged graph using an optional base URL.
  • Pasted JSON-LD. Parses 1 JSON value directly, applies an optional base IRI and validates the resulting JSON-LD document.
  • Local text file. Accepts .html, .htm, .json and .jsonld files within service limits, then applies the matching HTML or JSON-LD workflow.

URL input represents an anonymous public retrieval, not a logged-in visitor session. Authenticated pages, personalisation, consent choices and geographic variation can expose different material, so the result identifies the view that was actually tested and does not imply coverage of those unseen states.

03Why valid has several meanings

Structured-data validation is not one single universal test. A document can contain valid JSON yet fail during JSON-LD processing; processable JSON-LD can use recognised Schema.org terms while missing a property required by a Google Search feature. Even when that feature’s technical requirements are met, page evidence may remain unavailable or directly contradict the public markup.

A combined score conceals those necessary authority boundaries. The summary therefore reports each validation layer on its own terms, then surfaces the findings with the greatest consequence inside their stated scope.

  • JSON syntax. Can a conforming parser interpret the submitted source without ambiguity? RFC 8259 and duplicate-name interoperability controls.
  • HTML extraction. Can JSON-LD blocks be located and read from the supplied page representation? JSON-LD HTML embedding and extraction behaviour.
  • JSON-LD processing. Can a JSON-LD 1.1 processor expand the document without a normative processing error? W3C JSON-LD 1.1 and its Processing Algorithms and API.
  • Graph integrity. Do identifiers, relationships, value objects, lists and references form a coherent graph? W3C processing semantics and documented integrity rules.
  • Schema.org vocabulary. Are terms recognised, current and used consistently with the published vocabulary model? Pinned Schema.org 30.0 release data.
  • Consumer profile. Does the relevant entity meet a named consumer’s published technical requirements? Dated Google Search consumer rule bundles.
  • Page evidence. Is the markup present, retrievable, renderable, crawlable and consistent with available page facts? Published policies and observable page evidence.
  • Advisory quality. Does the source contain a maintainability or modelling weakness outside external conformance? Visibly labelled product-authored guidance.

The validation layers do not overrule one another. IETF rules determine whether the source is interoperable JSON, and W3C Recommendations govern JSON-LD processing. Schema.org release data supplies vocabulary knowledge and term status across the released vocabulary and ecosystem. Published consumer documentation adds requirements only within the named consumer profile, leaving the broader standards result intact.

Page evidence records only facts the product can observe reliably. Product-authored advice covers maintainability or modelling concerns, never a standards obligation. The displayed authority class makes the difference visible at the point of use. That distinction and any evidence the product cannot establish remain visible in exports and repeated-result comparisons, rather than being inferred from severity alone.

04Who it is for

The product serves people who need different levels of the same evidence. Developers receive exact syntax diagnostics, source pointers, repeatable outputs and correction guidance. Search specialists can distinguish required properties from recommendations, inspect page evidence and compare raw markup with the rendered document. Structured-data specialists can follow expanded entities, inherited vocabulary, domains, ranges, term status and graph relationships.

Product and content owners see the consequence first. They can hand the finding to a technical colleague without translating an opaque score or losing its source evidence.

05What it does not do

The validator's conformance assessment is limited to JSON-LD. It can detect RDFa or Microdata, but it does not claim conformance testing for either format. It also does not crawl an entire site, enter authenticated pages, imitate a personal browser state, edit a source system or submit URLs to a search engine. The product observes those systems; it does not act on them.

Its supported product surface is the public web interface. Persistent accounts, site-wide monitoring and unrestricted batch crawling sit outside the current boundary, and each suggested correction remains under user control. Factual review is required before any change reaches a live page.

An identifier appearing in the graph does not trigger automatic dereferencing. External retrieval occurs only when JSON-LD processing or a selected page check requires a document, context or asset, and that request crosses the same controlled network boundary as other public retrieval. This keeps reference discovery separate from network access and records the retrieval decision in processing evidence.

06Where this sits with AI Readiness

AI Readiness is the outside-in view: how AI systems find, read and represent an organisation from the public information they can reach. Structured data is the most explicit statement a page makes to a machine, and among the easiest to get wrong without anyone noticing.

The validator tests that statement against its governing standards, 1 authority at a time. It is the narrow instrument. AI Readiness is the wider position it belongs to.