Schema Visualizer: JSON-LD Graph & Validator

By Linus Li · Updated 2026-10-01 · Free, runs in your browser

Rate this tool1 rating so far

Enter a URL or paste JSON-LD below and the tool draws its entities as a graph, checks them against schema.org and Google Search Central requirements, and generates corrected code for everything it can fix automatically. Pasted markup is processed only in your browser and never uploaded.

How to use it

Paste into the box on the left: a JSON-LD snippet, JSON with @graph, or the full HTML source of a page. With HTML, every <script type="application/ld+json"> is extracted automatically.
Click “Generate graph” or press Ctrl / ⌘ + Enter.
Drag the graph to pan; hold Ctrl / ⌘ and scroll to zoom. Click any node to see all of its properties and its raw JSON in the inspector.
Switch between four views at the top right: Graph, Entities, What machines read and Auto-fix. The “Checks” tab below lists errors and suggestions; click one to jump to its node. “Rich results” shows which Google rich result types the page may qualify for and whether their required fields are present.

Auto-fix, What machines read and Entities

Auto-fix lists everything the tool can correct and gives you the full corrected code to copy. It currently handles currency symbols and thousands separators in prices, lowercase currency codes, free-text availability such as “In stock”, non-standard dates such as 2026/12/31, plain-text authors, protocol-relative URLs, wrongly cased @type values and property names, empty values and duplicate sameAs URLs, mismatched @id references and breadcrumb numbering. Enter the page URL and it also turns relative URLs into absolute ones and gives the page’s only organization and website a stable @id. The quality score before and after is shown side by side. Unrendered template variables and missing content need human judgement, so the tool never invents data for you.

What machines read turns the markup into a sentence, such as “A product: XX jacket, brand XX, priced at 1299 USD, in stock, rated 4.7 (23)”. Values that are malformed and may not be read are flagged. Use it to explain to colleagues or clients who do not read code what search engines and AI can take directly from the page, and what is missing entirely.

Entities shows the organizations, people, websites and brands on the page as cards with their name, @id, linked external profiles and who references them. Each card has an entity completeness checklist: does the organization have a stable @id, a logo, at least two sameAs links, a Wikipedia or Wikidata link and contact details; is the author linked to their organization. These signals decide whether search engines can match your brand and authors with entities in their knowledge graphs.

The quickest way to check a page is to enter its URL: our server fetches the page and extracts its JSON-LD. A server fetch sees the raw HTML, so structured data injected by JavaScript (Shopify apps, tag managers) is not included. For those pages, use the bookmarklet inside the tool: drag it to your bookmarks bar and click it on the page, and every JSON-LD block the browser actually rendered is copied to your clipboard, ready to paste.

Reading the graph

Each card is one entity. The first line is its @type, the second its @id if it has one. There are two kinds of connection:

Solid red lines mean nesting: one entity is written inside a property of another, such as an Offer inside a Product‘s offers.
Dashed blue lines mean an @id reference: the property only contains {"@id": "..."} and points to an entity defined elsewhere on the page, such as a BlogPosting‘s author pointing to a Person.

A card with a dashed border means that @id is not defined on this page. If it is defined on another page of your site, that is a normal cross-page reference. If you meant to reference an entity on this page, the two @id values usually differ by a trailing slash or similar.

Why @id matters

Structured data is not only about stars and prices in search results. Google and AI search engines also use it to work out which brand or author a page is about. If the same organization is described separately on the home page, articles and product pages without a shared @id, search engines have to guess whether those descriptions are the same entity.

The safer pattern is to fix one @id for the whole site, such as https://example.com/#organization, write the full properties once, and use {"@id": "https://example.com/#organization"} everywhere else. The tool flags:

Organization, Person and WebSite entities without an @id
an organization with the same name defined more than once on the page
a referenced @id that differs from a defined one only by a slash, letter case or www

For practitioners: the full list of checks

Syntax and vocabulary

JSON syntax errors, with hints for trailing commas and curly quotes
missing @context, or a context that is not schema.org
@type spelling and case (over 300 common types are built in; types outside the list get a note, not a penalty)
capitalized property names and invalid JSON-LD keywords such as @Type

Values

relative or protocol-relative URLs in url, image, logo, sameAs, item and similar properties
dates that are not ISO 8601, and times without a time zone
price with currency symbols or thousands separators; priceCurrency that is not an ISO 4217 code
availability and itemCondition values outside the schema.org enumerations
ratingValue outside bestRating / worstRating, and zero review counts
GTINs with the wrong number of digits
unrendered template variables ({{ }}, {% %}, ${}), common in Shopify themes and apps
empty values, placeholder text and duplicate sameAs URLs

Required and recommended properties by type

Covers Article and its subtypes, Product, Offer, AggregateOffer, Review, AggregateRating, BreadcrumbList, LocalBusiness and its subtypes, Organization, Person, Event, Recipe, VideoObject, JobPosting, SoftwareApplication, FAQPage, ProfilePage, DiscussionForumPosting, QAPage, Dataset and more. Required properties follow the Google Search Central documentation for each rich result and count as errors; missing recommended properties count as suggestions.

Retired or limited features

FAQ rich results have been limited to well-known government and health sites since August 2023
HowTo rich results were retired in 2023
The sitelinks search box was retired in November 2024

Scoring: start at 100, subtract 15 per error, 5 per warning and 2 per suggestion; notes are free. The score reflects how complete the markup is, not whether Google will show a rich result.

FAQ

How does fetching a URL work?

The browser’s same-origin policy stops scripts on one site from reading another, so when you enter a URL our server fetches the page for you. It returns only the page’s JSON-LD and canonical URL and stores no page content. To prevent abuse, fetching is rate limited (30 per IP per hour, 150 per day), and the same URL checked again within 10 minutes is served from cache. The fetcher identifies itself as LinusSEO-Tools/1.0 and can reach public URLs only.

How is this different from Google’s Rich Results Test?

Google’s Rich Results Test fetches and renders the live page, so treat its verdict as final. This tool focuses on how entities connect and adds checks Google’s test does not report, such as duplicate organizations, mismatched @id values and unrendered template variables. Use both. The Schema Markup Validator checks the schema.org vocabulary only, not Google’s requirements.

Is my markup uploaded or stored?

Pasted markup is not. Parsing, drawing and checking happen locally; only when you enter a URL is that URL sent to our server to fetch it. Your last input is kept in your browser’s localStorage for convenience; “Clear” deletes it. “Copy share link” compresses the markup into the part of the URL after #, which browsers never send to the server.

Does a score of 100 guarantee rich results?

No. Google also considers page quality, whether the content matches the markup, and whether the feature is available in your region.