JSON-LD Generator

Generated result

{{ schemaLabel }} {{ propertyRows.length }} fields {{ blockingIssues }} blockers {{ reviewIssues }} review notes

Schema type:

Start with the main entity on the page; the output updates instantly.

Page URL:

Use an absolute https:// URL for the published page.

{{ nameLabel }}:

Description:

Keep this aligned with text users can actually see on the page.

{{ imageLabel }}:

Article subtype:

BlogPosting and NewsArticle are still Article subtypes.

Author name:

Use the byline shown on the article page.

Publisher name:

Use the site or organization name that publishes the page.

Date published:

Use the date visible on the article page.

Date modified:

Leave equal to published date when there is no separate update date.

Brand name:

Include the visible brand when the product page shows one.

SKU:

Optional product identifier for catalog and merchant pages.

Offer price:

Leave price blank for non-commerce product information pages.

Availability:

Choose the visible offer state, or omit when the page has no offer.

Organization subtype:

LocalBusiness and OnlineStore are useful when they describe the real entity.

Telephone:

Use the same number shown on the organization page.

Email:

Use a public contact address, not a private mailbox.

SameAs URLs:

Enter one official profile URL per line.

FAQ pairs:

Format each row as Question | Answer. Mark up only FAQ content visible on the page.

Review before publishing

{{ issue.detail }}

Entity @id:

Use a canonical URL with a fragment such as https://www.example.com/about#organization.

Minify generated code:

Use compact output when pasting into production templates; keep it off while reviewing fields.

Status	Scope	Detail	Next step	Copy
{{ row.status }}	{{ row.scope }}	{{ row.detail }}	{{ row.nextStep }}

JSON path	Value	Purpose	Copy
{{ row.path }}	{{ row.value }}	{{ row.purpose }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Structured data gives machines a cleaner way to understand a page than ordinary text alone. A person can see that a page is a product listing, an article, an organization profile, or a question-and-answer page because the layout and wording make that obvious. A crawler or validator needs explicit clues. JSON-LD supplies those clues as a JSON graph that says what the main entity is, which vocabulary defines the terms, and which page-visible facts belong to that entity.

The common vocabulary for web structured data is Schema.org. It provides type names such as Article, Product, Organization, and FAQPage, plus properties such as headline, image, price, logo, sameAs, and acceptedAnswer. JSON-LD is one way to write that vocabulary on a page. It keeps the structured-data block separate from the visible HTML, which makes it easier to maintain than attributes sprinkled through every heading, price, or answer.

Good markup is not a wish list for search features. It is a factual description of the page. A product price should match the offer shown to shoppers, an article author should match the visible byline, and a FAQ answer should be available to readers on the same page. Markup can be valid JSON and still be wrong if it describes hidden, stale, exaggerated, or unrelated content.

Rich results add another limit. Search engines may use structured data to understand a page, and some page types can become eligible for enhanced search appearances, but eligibility is not a guarantee. The final decision can depend on content quality, crawler access, feature-specific rules, the search query, and whether the deployed page follows current policies. FAQ markup is a useful example: the question-and-answer graph can be technically valid, while rich-result display is limited by stricter content and site-category rules.

Graph: The machine-readable entity description written as JSON-LD.
Type: The Schema.org class that most accurately matches the page's main entity, such as Article or Product.
Property: A named fact attached to the entity, such as headline, brand, logo, or acceptedAnswer.
Content match: The practical check that every important structured-data claim reflects visible page content.

How to Use This Tool:

Use the generator as a drafting and review workspace for one page at a time. Start with the entity the page is mainly about, then add only the fields that readers, crawlers, and reviewers can verify on that page.

Choose Schema type. Use Article for editorial pages, Product for a product detail or merchant page, Organization for a public entity profile, and FAQ Page only when the page contains visible question-and-answer content.
Enter the Page URL as an absolute HTTP or HTTPS URL. This should be the canonical page where the markup will be published.
Fill the main name field. For Article, use the visible headline. For Product and Organization, use the public name shown on the page. FAQ Page can use a page name when that helps identify the content.
Add fields that match the selected type. Article can include subtype, author, publisher, image, and dates. Product can include brand, SKU, price, currency, and availability. Organization can include subtype, logo, public contact details, and official profile URLs.
For FAQ Page, write one question-and-answer pair per line as Question | Answer. Rows without both sides are flagged because a complete question needs an accepted answer.
Use Entity @id only when you have a stable identifier, such as a canonical URL with a fragment. Leave it blank when the identifier would be temporary or guessed.
Review Markup Audit before copying. Fix Missing rows first, then decide whether Review rows need correction, removal, or an intentional blank value.
Copy the Script Tag for page templates, or use the JSON tab when you need the raw graph for review. Download audit and ledger tables when you need a handoff record.

Interpreting Results:

The generated script is a structured-data draft. It can be syntactically ready while still needing editorial judgment. The graph should identify the right Schema.org type, point to the right page, and describe the same facts a visitor can find without inspecting source code.

The summary badge shows the selected type, the number of generated property rows, and whether blockers or review notes remain. A blocker means the current draft is not ready to publish for the selected type. A review note means the graph may still be usable, but the value deserves a human check before deployment.

Script Tag is the copy-ready block for an HTML page. Use readable output while reviewing and minified output when a compact template snippet is more convenient.
Markup Audit turns field quality checks into Pass, Review, Missing, and Info rows. A Pass row does not promise rich-result display; it only means that check passed.
Property Ledger lists each emitted JSON path, value, and purpose so you can spot stale names, blank optional fields, unexpected offer data, or profile URLs that do not belong to the same entity.
JSON shows the graph without the surrounding script tag. It is useful for schema review, version control notes, or a validator that accepts raw JSON-LD.

Technical Details:

JSON-LD works by assigning meaning to ordinary JSON keys. The @context value tells processors which vocabulary defines the terms, and the @type value states the class of entity being described. A stable @id can identify the entity across pages or updates, especially when related markup needs to point to the same organization, product, article, or page object.

Schema.org terms are broad, so the most specific useful type usually produces the clearest graph. Article, BlogPosting, and NewsArticle all describe editorial content, but the more specific subtype should match the real page. Organization, LocalBusiness, OnlineStore, and Corporation have a similar relationship. Specificity helps only when it remains true to the page; an over-specific type can be more misleading than a general one.

Transformation Core:

The graph is assembled from a small set of typed facts. Blank optional values are omitted rather than emitted as empty properties, which keeps the output cleaner and prevents false signals from placeholder fields.

How selected page types map to JSON-LD graph properties
Selected page type	Core graph shape	Field checks that matter most
Article	Uses the chosen article subtype, headline, description, image array, publication and modified dates, author, publisher, logo, and a main page identity when supplied.	Headline, byline, dates, publisher, image, and canonical URL should match the article page.
Product	Uses Product with name, description, image, SKU, brand, and an Offer containing URL, price, currency, and availability when offer fields are present.	Price must be non-negative, currency should match the displayed offer, and availability should reflect the live commerce state.
Organization	Uses the chosen organization subtype with name, URL, logo, description, sameAs profile URLs, and a public contact point when contact details are entered.	Logo and profile URLs should be official, crawlable, and tied to the same public entity.
FAQPage	Uses FAQPage with optional page name and URL, plus one Question object for each complete question-and-answer row.	Every question and answer should be visible on the page, and each row needs both parts.

Validation Boundaries:

JSON syntax, Schema.org vocabulary, and rich-result eligibility are separate concerns. A script can parse correctly, use recognized terms, and still fail a search policy or content-match check. The safest review order is syntax first, page match second, then feature-specific eligibility.

Structured data review boundaries
Boundary	What it proves	What it does not prove
Valid JSON-LD	The markup can be parsed as JSON-LD and placed in an `application/ld+json` script block.	It does not prove the facts are true, current, visible, or eligible for a search feature.
Schema.org type	The graph uses a known vocabulary and a recognizable entity type.	It does not guarantee that every search engine supports the same properties or presentation.
Visible content match	The structured-data claims describe information readers can verify on the page.	It does not guarantee rich-result display, ranking changes, or instant crawler updates.
Published URL test	The deployed page exposes the final markup where crawlers can inspect it.	It does not catch every policy problem, stale value, or future feature-rule change.

The sameAs property deserves special care because it disambiguates identity. Use official profiles or knowledge pages for the same organization, not loosely related accounts, partner pages, or pages controlled by a different entity. For product offers, treat price and availability as time-sensitive data; stale offer markup can become misleading even if it was accurate when first generated.

Advanced Tips:

Choose the narrowest true subtype only when the page supports it. BlogPosting, NewsArticle, LocalBusiness, and OnlineStore help only when they describe the real page or organization.
Use Entity @id for durable identities, not one-off drafts. A canonical URL with a stable fragment is easier to maintain across templates than a temporary staging address.
Keep readable output while checking Markup Audit and Property Ledger. Turn on minified output only after the graph's content and page match have been reviewed.
For product pages, recheck Offer price, currency, and Availability whenever the commerce system changes. Offer markup can become misleading faster than article or organization facts.
Use the audit and ledger downloads for handoff reviews. They make it easier to show which values were emitted, which rows were omitted, and which review notes were intentionally accepted.

Limitations and Privacy Notes:

This tool assembles the JSON-LD draft in the browser and does not need a server lookup to generate the graph. The details you enter are still meant for public markup, so avoid private contact information, unpublished prices, internal SKU notes, or test-only profile URLs unless you are working in a private draft environment.

Automated checks cannot know whether an image is truly crawlable after deployment, whether a page template changes the final output, or whether a search feature will be shown for a particular query. Validate the final published URL after adding the script, especially for product pages, article pages with changing dates, and FAQ pages that may be subject to stricter feature rules.

The generator covers a focused set of common page types. More specialized pages may need additional Schema.org types or properties beyond the fields here. In that case, use the output as a starting point and extend it carefully against the official type documentation.

Worked Examples:

An editorial page titled Launch Readiness Checklist with author Jordan Lee, publisher Example Editorial, an HTTPS canonical URL, and visible publication dates can produce an Article graph with headline, author, publisher, dates, image, and main page identity. The remaining review is not syntax; it is whether each value still matches the final article page.

A product detail page for Launch Readiness Workbook can include SKU, brand, image, price, currency, and availability. If the offer price is 49.00 and the currency is USD, the generated Offer can state those values. A blank price can be reasonable for a non-commerce information page, but a merchant page should not publish stale or mismatched offer data.

A FAQ page row written as Where should I add JSON-LD? | Place the script in the page head or body. becomes one complete question with an accepted answer. A row with only a question is flagged because it would create an incomplete FAQ entry, and a row copied from content that is not visible on the page should be removed before publishing.

FAQ:

Can valid JSON-LD still be bad structured data?

Yes. Valid syntax only means the block can be parsed. The structured data still needs to describe the right entity, use suitable properties, and match visible, current page content.

Where should I place the script tag?

JSON-LD is commonly placed in the page head or body in a script block with the application/ld+json type. Place it on the page it describes, then test the final published URL.

Should I minify the output?

Readable output is easier to review. Minified output is fine after review because it changes whitespace, not the graph's meaning.

Does FAQPage markup still matter if rich-result display is limited?

It can still describe visible question-and-answer content, but it should not be added only for a visual search treatment. Follow current feature guidance and mark up only FAQs that readers can access on the source page.

What should I do with Review rows?

Treat them as judgment checks. Correct invalid URLs, remove values that are not public or visible, and leave optional fields blank when the page does not support them.

Glossary:

JSON-LD: JSON for Linked Data, a JSON-based format for describing linked entities and facts.
Schema.org: A shared vocabulary of types and properties used by many structured-data consumers.
@context: The JSON-LD keyword that points to the vocabulary used by the graph.
@type: The JSON-LD keyword that identifies the kind of entity being described.
@id: An optional stable identifier for an entity, usually a canonical URL or URL fragment.
sameAs: A Schema.org property for official profile or identity URLs that refer to the same entity.

References:

JSON-LD 1.1, W3C Recommendation.
Getting started with Schema.org, Schema.org.
Intro to how structured data markup works, Google Search Central.
General structured data guidelines, Google Search Central.
FAQ structured data, Google Search Central.