JSON-LD Validator

JSON-LD stands for JavaScript Object Notation for Linked Data. It's a way to add structured data to your web pages using a standardized format that search engines can read and understand. The code sits inside a <script type="application/ld+json"> tag in your page's HTML, usually in the head section, though it works in the body too.

Structured data tells search engines exactly what your content is about in a language they can parse directly. Instead of guessing that a block of text is a recipe, a product listing, or a business address, the search engine reads your JSON-LD and knows for certain. That clarity is what powers rich results like star ratings, FAQ dropdowns, recipe cards, event listings, and product pricing in search results.

Google has stated that JSON-LD is their preferred format for structured data over alternatives like Microdata and RDFa. It's also the easiest to implement since it doesn't require weaving attributes into your existing HTML markup.

The JSON-LD Validator runs your code through several layers of checks to catch issues that could prevent rich results or cause search engines to ignore your structured data entirely.

Syntax validation. The tool first checks whether your code is valid JSON. Missing commas, unclosed brackets, trailing commas, and unquoted keys are common problems that break the entire block. Even one syntax error means search engines can't parse any of your structured data on that page.

Schema.org compliance. Once the syntax passes, the tool checks your markup against Schema.org vocabulary. It verifies that the types you're using actually exist, that properties belong to the correct types, and that values match expected data formats. Putting a text string where Schema.org expects a date, or using a property that doesn't exist on your chosen type, will get flagged here.

Required and recommended properties. Google and other search engines require certain properties for each schema type before they'll generate rich results. An Article type needs a headline and author. A Product type needs a name and at least one offer. This tool flags missing required properties and also calls out recommended properties that improve your chances of earning rich results.

Nesting and relationship errors. JSON-LD allows you to nest objects inside each other to describe relationships. A Product contains an Offer, which contains a price and currency. The validator checks that nested objects use the correct types and that relationships between them make sense according to the Schema.org spec.

The validator supports all Schema.org types, but the most commonly validated ones include Article, Product, LocalBusiness, FAQPage, HowTo, Recipe, Event, Organization, Person, BreadcrumbList, VideoObject, and Review. These are the types Google actively uses to generate rich results.

If you're using a less common type or a custom extension, the tool still validates your JSON syntax and checks property names and value formats against the Schema.org vocabulary. You'll get useful feedback regardless of which type you're working with.

Google's Rich Results Test only checks whether your markup qualifies for Google's specific rich result features. It focuses on a limited set of schema types that Google currently supports and evaluates them against Google's requirements, which sometimes differ from the broader Schema.org spec.

This validator checks your JSON-LD more broadly. It catches syntax errors, validates against the full Schema.org vocabulary, and flags structural issues that Google's tool might not surface. It also doesn't require a live URL, so you can validate your code during development before anything is published.

The best workflow is to use both. Validate your code here first to catch syntax and structural problems, then run it through Google's tool to confirm it qualifies for the specific rich result you're targeting.

Invalid JSON syntax. This is the number one issue. A missing comma between properties, a trailing comma after the last property, or mismatched brackets will break the entire block. JSON is strict about formatting in ways that JavaScript is not, and that trips people up constantly.

Wrong value types. Schema.org expects specific data types for each property. A date field should use ISO 8601 format like "2025-04-07", not "April 7, 2025." A URL property should contain a full URL, not a relative path. Price should be a number or string representation of a number, not "twenty dollars."

Using properties on the wrong type. Every Schema.org type has a defined set of valid properties. Adding a "cookTime" property to an Article type or "author" to a Product type will generate errors. Check the Schema.org documentation for which properties belong to which types.

Missing @context or @type. Every JSON-LD block needs "@context": "https://schema.org" and a "@type" declaration. Without these, search engines don't know how to interpret your data. It's easy to forget one or the other when building markup from scratch.

Outdated or deprecated types. Schema.org evolves over time. Types and properties get deprecated and replaced. If you copied markup from an old tutorial or template, some of what you're using may no longer be valid or recommended.

Yes. Many pages have more than one JSON-LD block, and that's perfectly valid. You might have a BreadcrumbList, an Article, and an Organization block all on the same page. Paste all of them into the validator and each block will be checked independently.

If you enter a URL instead of pasting code, the tool will find and validate every JSON-LD block on that page automatically. This is useful for catching issues across your full structured data setup without having to inspect the source and copy each block manually.

Structured data is not a direct ranking factor. Adding JSON-LD to your pages won't move you up in the search results by itself. Google has been clear about this.

What structured data does is qualify your pages for rich results, and rich results consistently earn higher click-through rates than standard blue links. A product listing with star ratings, price, and availability information stands out visually and gives searchers more reasons to click. An FAQ result that expands directly in the SERP can dominate more real estate on the page.

Higher click-through rates can indirectly improve rankings over time, and rich results make your existing rankings more valuable by converting more impressions into clicks. So while JSON-LD doesn't boost rankings directly, the downstream effects on traffic and engagement make it well worth implementing.

Keep your structured data accurate. The information in your JSON-LD should match what's visible on the page. If your markup says a product costs $29.99 but the page shows $39.99, that's a policy violation that can result in manual actions from Google.

Don't mark up content that isn't visible to users. Structured data should describe content that people can actually see on the page. Adding schema for content that only exists in the code is considered spam by search engines.

Use the most specific type available. If you're marking up a restaurant, use Restaurant instead of the more generic LocalBusiness. More specific types give search engines better context and may qualify you for additional rich result features.

Validate after every change. Any edit to your JSON-LD, no matter how small, can introduce errors. Run your code through the validator after every update, especially after CMS updates, theme changes, or plugin modifications that might touch your structured data output.

Test across page templates, not just individual pages. If your CMS generates JSON-LD dynamically, validate at least one page from each template type. An error in a template affects every page using it, so catching it early saves you from hundreds of broken schema blocks.