Schema.org JSON-LD Builder
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article"
}
</script>Structured data is the difference between a plain blue link and a search result that pulls a star rating, a price, an FAQ accordion, a recipe time, or a sitelinks search box into the page. Google, Bing, Yandex and most modern search engines rely on Schema.org vocabulary to understand what a page is about beyond the words on it, and the recommended encoding has been JSON-LD since the rich results program became a real ranking and CTR signal in the mid-2010s. Despite how important this signal is, the actual authoring experience is still surprisingly painful: documentation is split across schema.org and Google's search central, the JSON-LD spec has a steep learning curve if you have not written it before, and the most common authoring mistakes — stale dateModified, missing absolute image URLs, Product without offers — all silently fail validation rather than producing a hard error you can catch in CI.
This builder is designed to remove that friction for the cases that actually win rich results in 2026: Article (and its NewsArticle / BlogPosting subtypes), Product, FAQPage, LocalBusiness, and BreadcrumbList. Those five types together cover the vast majority of pages on a typical content site, e-commerce store, or local-services business. The form gives you exactly the fields Google's rich results documentation calls out as required or strongly recommended, with inline hints for the gotchas that fail validation most often. As you type, a live JSON-LD preview updates on the right, properly indented, with the @context and @type set automatically. When you are happy, the Copy button gives you a clean snippet wrapped in a <script type="application/ld+json"> tag that you can paste directly into the <head> of the relevant page.
It helps to know a little of why JSON-LD won. Schema.org defines three serializations — Microdata, RDFa, and JSON-LD — and for the first few years of the project, the recommendation was Microdata, which embeds attributes directly into the HTML markup. The advantage was that the structured data lived next to the content that produced it; the disadvantage was that templates became cluttered with itemprop, itemscope, and itemtype attributes that engineers found unreadable, and dynamic pages that re-rendered on the client had to be careful to keep the markup in sync. JSON-LD ships the structured data as a separate JSON block, completely decoupled from the rendered HTML. This makes it trivial to generate at the server layer or as a static asset, and it survives client-side rerenders without a single template change. Google announced first-class JSON-LD support in 2015, and by 2018 it was the recommended serialization across most rich result types. Today, almost every modern CMS and SEO tool emits JSON-LD by default.
Article is the bread and butter of content sites. Google requires headline (≤110 characters in practice for clean SERP rendering), image (one or more absolute URLs, ideally high-resolution at 1200px wide for the large image cards), datePublished in ISO 8601, and an author. dateModified is optional but strongly recommended — Google uses it to decide whether to refresh the cached snippet, and a missing or stale dateModified is a common reason articles fail to surface in Top Stories. The publisher field is required for AMP and recommended otherwise; the publisher's logo should be at least 60×600 pixels, with absolute URLs in both image and logo. The builder enforces the ISO date format via the datetime-local input and lets you supply both author and publisher with the right nesting under @type Person and @type Organization respectively, which is the most common mistake when authors copy a flat object example from Stack Overflow.
Product is the highest-leverage type for e-commerce, and also the trickiest because Google's policies tightened significantly in 2022 and 2023. The required fields are name, image (absolute URL), and offers — without offers, the product will not appear in product rich results at all. The price must be a string in the offers.price field (not a number, despite JSON allowing numbers), and the currency must be a three-letter ISO 4217 code in priceCurrency. The availability field uses Schema.org URL values like https://schema.org/InStock — the builder writes these correctly so you do not have to memorize them. AggregateRating used to be a way to surface star ratings, but Google now requires that the ratings come from real, verifiable user reviews on the same product, and self-attributed ratings can lead to manual actions. The builder includes the aggregateRating fields but you should only fill them in when you can back them up.
FAQPage went through an interesting trajectory: it was a rich result darling from 2019 to 2023, and Google then announced that FAQ rich results would be limited to government and well-known authoritative health sites in August 2023. The structured data still has value — it appears in some non-Google surfaces, it can drive AI Overview citations, and Google still parses it for entity extraction — but you should set realistic expectations. The builder validates that each Q&A has both a question and an answer (Google's parser drops items that are missing either), and produces a mainEntity array with the right Question / Answer nesting. A common mistake is to have FAQPage on a page where the Q&As are hidden behind clicks; Google's policy requires all the answer text to be visible without user interaction, so an accordion that loads content from JavaScript on click can be flagged as cloaking.
LocalBusiness is the workhorse for any address-based business that wants to appear in Google's local pack with proper business hours, photos, and a directions card. The builder offers the most useful subtypes (Restaurant, Store, MedicalClinic, etc.) because Google strongly prefers the most specific type that fits — a Restaurant typed as LocalBusiness will work but will surface fewer rich features than one typed as Restaurant. The address field is a nested PostalAddress with the standard fields; the addressCountry should be a two-letter ISO 3166-1 code (US, GB, TR), not the full country name, even though many examples online use the full name. openingHours is the field that trips up the most authors — it uses a dense format like "Mo-Fr 09:00-18:00" or "Sa 10:00-16:00" with day codes, and you can supply multiple lines for multiple ranges. The builder accepts one range per line and joins them into the array Schema.org expects.
BreadcrumbList is the cheapest rich result win on a content site. It signals to Google the hierarchy of the current page in a site's information architecture, and Google uses it to build the breadcrumb trail that appears below the page title in mobile SERPs. The format is an itemListElement array of ListItem entries, each with a position (1-indexed), a name, and an item (an absolute URL). Two mistakes account for almost all BreadcrumbList rendering failures: relative URLs in the item field, and a 1-off in the position numbering when the array is built dynamically. The builder enforces 1-indexed positions and assumes absolute URLs, with an inline hint when an entry looks like a relative path. Pairing BreadcrumbList with Article or Product on the same page is best practice — they reinforce each other and give Google a fuller picture of what the page is.
Validation is the step everyone skips and then regrets. Google's Rich Results Test (search.google.com/test/rich-results) is the canonical tool: it fetches the URL or accepts pasted code, runs it through Google's actual parser, and reports both validation errors and which rich result categories the page is eligible for. The Schema.org validator (validator.schema.org) is more permissive and useful for general structured data work but does not check Google-specific requirements. Schema.org's documentation occasionally lags behind Google's actual rendering rules, so when the two disagree, trust the Rich Results Test for SEO purposes. The builder generates output that passes both validators on the happy path; if a field is empty, the corresponding key is omitted from the output rather than emitted as an empty string, because empty values often trigger validation warnings.
On implementation, the recommended placement is inside the <head> of the page, but Google also accepts JSON-LD anywhere in the body — useful when your CMS does not give you head-level control. You can ship multiple separate <script type="application/ld+json"> blocks, or you can combine them under a single @graph array, which is the cleaner pattern for pages that need both BreadcrumbList and Article (or Product, etc.). The builder generates one block at a time so you can keep the source of truth simple and concatenate yourself, or use the @graph pattern manually when you ship. Either way works for Google. Avoid one mistake: do not embed JSON-LD inside a Mustache or Handlebars block that escapes quotes — escaped JSON breaks the parser. Always render it raw.
Privacy and security are simple here because everything happens in your browser. The form state lives in React state; the JSON serialization is a pure function on that state; nothing is uploaded to any server, no telemetry tracks the contents of your form, and you can author structured data for unannounced products or unpublished blog posts without leaking anything. If you are working in a corporate environment with strict outbound-content policies, this matters: a typical online schema generator uploads your draft fields to its server every time you change anything, which is not always allowed. This builder does not, and you can verify by opening the browser network tab and watching: there are no requests during editing.
A few practical patterns worth highlighting. First, write your schema once and treat it as part of your page template — not as a one-off paste. Articles benefit from a partial that takes title, image, dates, and author and produces the JSON-LD; Product benefits from a partial that takes the same data your product detail page renders. This way the structured data and the visible content stay in sync. Second, use dateModified honestly — Google watches for sites that bump dateModified daily without changing the article, and that pattern can lead to a Top Stories deprioritization. Third, use only one canonical URL across breadcrumb, article and product schemas on the same page; mixing canonical hosts (www vs apex, http vs https) confuses the indexer.
This tool pairs naturally with the rest of Omnvert's developer utilities. After generating the JSON-LD, you can paste the output into the JSON Viewer to sanity-check the tree structure visually, or run it through the Regex Tester if you need to bulk-replace a token across a large schema. The Open Graph & Twitter Card Preview tool covers the related but different problem of making sure your social previews are correct — JSON-LD targets search engines, while OG and twitter:card target social platforms. Most production pages need both. The Hash Generator is useful when you need a stable @id URI for resources that do not have a natural URL. All of these run in the browser with the same privacy model, so an entire SEO authoring workflow can happen in a single tab without a single request to a third-party service.
- Add Article structured data to a blog post with author, publisher, dates and a hero image.
- Generate Product schema for an e-commerce page with price, currency, availability and brand.
- Build a FAQPage block from a Q&A list and paste it into your CMS.
- Mark up a local business with address, phone, opening hours and geo coordinates.
- Add a BreadcrumbList to a category or detail page to win the SERP breadcrumb trail.
- Quickly mock up structured data for a draft page before validating with the Rich Results Test.
- Teach junior developers what a complete schema looks like by toggling through the templates.
- Audit existing pages by pasting reverse-engineered field values back into the form.
- 1Pick a template: Article, Product, FAQ, LocalBusiness, or BreadcrumbList.
- 2Fill in the form fields — only the fields that apply; empty fields are omitted from the output.
- 3Watch the JSON-LD preview build live as you type.
- 4Toggle the <script> wrapper if you want to paste directly into HTML, or copy raw JSON.
- 5Click Validate to open Google's Rich Results Test in a new tab.
- 6Copy or download the snippet and paste it into the head of your page.