JSON-LD Schema Generator
Pick a schema.org type, fill in the fields, and get valid JSON-LD structured data — ready to paste into your page's <head>. Covers the types that drive Google rich results: Article, FAQPage, BreadcrumbList, Organization, LocalBusiness and Product. Runs entirely in your browser.
About this tool
Pick a schema.org type, fill in the fields, and the tool assembles valid JSON-LD as you type — properly nested, with empty fields and empty nested objects dropped so you never ship a half-filled node. It covers the six types that drive Google rich results: Article, FAQPage, BreadcrumbList, Organization, LocalBusiness and Product. Flat form fields like "Author name" and "Publisher logo URL" are folded into the nested Person and Organization objects the spec expects; list-valued parts — FAQ questions, breadcrumb steps, image URLs, opening hours — are repeating rows you add and remove. A checkbox wraps the output in a <script type="application/ld+json"> tag ready to paste into the page head, and the tool flags any property Google requires for the rich result that you have left blank.
When to use it
Questions
What is JSON-LD and why does Google prefer it over microdata?
JSON-LD (JSON for Linking Data) is a single script block that describes the page's meaning — its type, title, author, price and so on — in a structured form search engines can read directly. Microdata and RDFa do the same job but by scattering attributes through the HTML, so the markup and the visible content are tangled together and easy to break during a redesign. Google's documentation recommends JSON-LD precisely because it sits in one place, is generated server-side or by a tag manager without touching the layout, and is the format its own tools and examples use. All three formats are still parsed, but new markup should be JSON-LD.
Where does the <script> tag go?
Anywhere in the page — <head> or <body>, Google reads it from either. The convention is to put it in the <head> alongside the other metadata, or to inject it at the end of <body> via a tag manager. What matters is that the exact block is present in the HTML Google receives; if it is added by client-side JavaScript after load, make sure the rendering path Google uses actually runs that script. Tick "Wrap in a <script> tag" to get the block with the correct type attribute already on it.
Does adding this markup guarantee a rich result?
No. Valid structured data makes a page eligible for a rich result; it does not entitle it to one. Google decides per query and per site whether to show the enhanced listing, and factors in site quality, whether the markup matches what a user actually sees, and whether the feature is available for your type and region. Treat the markup as necessary but not sufficient — a page with perfect JSON-LD can still show as a plain blue link.
Should a page have one @type or several?
One primary type that describes what the page is — an Article, a Product, a FAQPage. You can legitimately add more than one block when a page genuinely serves two roles, for example an Article that also carries a BreadcrumbList for the navigation path. What you should not do is claim a type the page is not; a blog post is not a Product just because it mentions one. This tool generates one type at a time — run it once per block and paste each into the page.
What is the @graph array?
@graph lets you put several related nodes in a single script block: instead of two separate <script> tags for an Article and its BreadcrumbList, you write one block whose @graph is an array of both nodes, often cross-referenced by @id. It is purely an organisational convenience — Google treats the nodes the same either way. This tool emits one node per run; if you prefer a single block, drop the two outputs into an @graph array yourself and give each an @id.
How do I test the output?
Two tools. Google's Rich Results Test (search.google.com/test/rich-results) tells you whether the markup makes the page eligible for a specific Google feature and shows the required/recommended warnings for that feature. The schema.org validator (validator.schema.org) checks the markup against the vocabulary itself without the Google-feature lens. Run the Rich Results Test when your goal is the search enhancement; use the schema.org validator when you just want to know the JSON-LD is well-formed. Both accept pasted code, so you can check before deploying.
How does nesting work for the author and publisher?
Article's author and publisher are not strings — they are nested nodes. author is a Person (or Organization) with its own name and url; publisher is an Organization with a name and a logo, and the logo is itself an ImageObject with a url. This tool takes the flat fields you fill in — "Author name", "Author URL", "Publisher name", "Publisher logo URL" — and builds those nested objects for you, omitting any level you leave empty. If you write the JSON by hand, that is the structure to reproduce.
What is sameAs for on an Organization?
sameAs is a list of URLs that unambiguously identify the same entity elsewhere — your company's LinkedIn page, X profile, Wikipedia article, Crunchbase entry. It helps search engines connect your Organization node to the wider web and to knowledge-graph data about you. Add the official profile URLs, not every page that mentions the company. In the tool it is the repeating "Social / profile URLs" field.
What happens if the markup and the visible page disagree?
Google's structured-data policies require the markup to describe content that is actually present and visible on the page. Rating stars in your JSON-LD with no reviews on the page, a price that differs from the one shown, FAQ answers that do not appear in the body — all of it risks a manual action that removes your rich results site-wide, not just on the offending page. Regenerate the block whenever the page content changes, and never mark up something a visitor cannot see.