Structured Data Testing Tool

Enter a URL or paste your markup, read the results, fix, and re-validate. There is no configuration, no account, and nothing to install.

1. 1

   Enter a URL or paste your markup

   Type a URL and click Fetch to pull all JSON-LD blocks from the page automatically. Or paste raw JSON, the full <script type="application/ld+json"> wrapper, or multiple blocks at once. The tool detects and validates each block independently.
2. 2

   Type detected automatically

   The validator reads each block’s @type and loads the corresponding type-specific rule set. A Product block gets Product rules, a Recipe block gets Recipe rules, and so on. If the @type is missing or unrecognised, that itself becomes the first finding.
3. 3

   Review validation results

   Errors appear in red and warnings in amber. Each finding shows the property path (e.g. offers.price), the current value, and a plain-language explanation of what is wrong. Scroll through the list or use the counts at the top for orientation.
4. 4

   Fix and re-validate

   Every finding includes a suggested replacement value. Copy the suggestion, update your markup, and paste the corrected version back. Results update live as you type, so you can watch findings disappear one by one.

Nine categories of rules run against every property in your JSON-LD. These are the value-level mistakes that syntax checkers and shape diffs miss completely.

URL format. Properties that expect a URL are checked for an absolute scheme. A relative path like "photo.jpg" fails because search engines cannot resolve it without a base URL. The suggested fix prepends https://example.com/ so you can see the expected shape and replace the domain with your own.

ISO 8601 dates. Date properties are validated against ISO 8601 format. Human-readable values like "March 5, 2024" and ambiguous formats like "03/05/2024" are flagged with a suggestion to rewrite as "2024-03-05". Google silently drops date values it cannot parse, so an invalid date means your rich result loses its date badge entirely.

ISO 8601 durations. Duration properties (like duration on VideoObject or cookTime on Recipe) must use the PT prefix format. Values like "4:50" or bare numbers like "290" are flagged with a suggestion like "PT4M50S".

Currency codes. The priceCurrency property is checked against the ISO 4217 list. A lowercase "usd" gets a suggestion to use "USD". Unrecognised codes like "DOLLARS" are flagged as invalid with a prompt to use the correct three-letter code.

Schema.org enum values. Properties that expect a schema.org enumeration value are checked for the correct namespace and casing. A bare "instock" gets corrected to "https://schema.org/InStock". The validator checks against the actual enum member lists from schema.org (ItemAvailability, OfferItemCondition, and others) so it catches typos and missing prefixes.

Number types. A price of "29.99" is technically a string, not a number. Google is forgiving about this, but the schema.org spec is not. The validator flags it with a warning and suggests the unquoted 29.99.

Position indexing. BreadcrumbList items use position to order the crumbs. Schema.org positions are 1-indexed, so a value of 0 is flagged with a suggestion to start from 1. This catches a common off-by-one error from looping over an array with a zero-based index.

Required-by-Google presence. For each recognised @type, the validator checks whether the fields Google marks as required are present. A Product block without offers.price gets an error because that field is required for the Product rich result. The rule sets are sourced from Google Search Central documentation.

@type validity. Every @type value is checked against the full schema.org type hierarchy (900+ types). A misspelling like "Prodcut" or a fabricated type like "WebArticle" is flagged immediately. If the type is close to a known type, the validator suggests the correct spelling.

Google’s Rich Results Test is the authoritative tool for confirming rich result eligibility. It crawls a live URL or accepts a code snippet, runs Google’s own parser, and returns a pass/fail verdict. For final pre-launch validation, nothing replaces it. But for iterative development, it has gaps this validator fills.

The Rich Results Test tells you that a property is invalid without showing you the exact value or suggesting a fix. The XooCode validator shows the property path, the current value, and a concrete replacement. When you are fixing five date fields across three JSON-LD blocks, the difference between “invalid value” and "2024-03-05" is significant.

The Rich Results Test requires a publicly accessible URL or a single code snippet. The XooCode tool also accepts a URL (and fetches JSON-LD blocks from it), but it works equally well with pasted localhost markup, staging environments behind VPNs, and blocks copied from a CMS admin panel. You can paste three or four JSON-LD blocks at once and validate them all in one pass. Google handles one snippet at a time.

The Rich Results Test takes a few seconds per submission. The XooCode validator returns results as you type. When you are working through five corrections in a row, that difference adds up fast.

The two tools are complementary. Use the XooCode validator during development to catch value-level mistakes early. Use the Rich Results Test before launch to confirm eligibility with Google’s own parser.

XooCode has two tools that accept a JSON-LD paste: the Schema Diff Tool and this validator. They look similar on the surface but answer different questions.

Schema Diff checks structural shape: which properties are present or missing compared to an XooCode reference example. It answers “what am I missing?” by listing every property the reference has that your markup does not, split by Google’s required, recommended, and optional buckets.

The validator checks value correctness: are the values in those properties formatted correctly? It answers “is what I have correct?” by inspecting URL formats, date strings, currency codes, enum values, number types, and required field presence.

The two are complementary. Run Schema Diff first to find properties you forgot to include. Then run the validator to confirm the values you already have are well-formed. A clean diff means you have the right properties. A clean validation means those properties have the right values. Between the two, you know your markup is both complete and correct.

The validator is deliberately focused on value-level correctness. Here is what falls inside that scope and what does not.

The validator’s rule sets reference several authoritative specifications. For deeper reading: schema.org defines the vocabulary and type hierarchy. Google Search Central structured data documentation lists the required and recommended fields for each rich result type. ISO 8601 (Wikipedia) covers the date and duration formats the validator checks against. ISO 4217 (Wikipedia) lists the three-letter currency codes used by the priceCurrency rule.