What JSON-LD is
Schema.org is a shared vocabulary — a list of types like Article, Recipe and LocalBusiness, each with properties like headline, cookTime and address. JSON-LD is one of three ways to write that vocabulary into a page, alongside Microdata and RDFa. The difference is that Microdata and RDFa are attributes sprinkled through your existing HTML, while JSON-LD is a self-contained block that names the same facts separately.
That separation is the reason JSON-LD has largely won. Your template markup stays clean, the structured description can be generated from the same data that rendered the page, and a mistake in one does not corrupt the other. The cost is that the two can drift apart, and drift is exactly what consumers of this markup check for.
The rule that matters more than the syntax
Markup has to describe what a visitor sees. An FAQ block listing questions that are not on the page, a price in the markup that differs from the price on the page, a review score with no reviews rendered anywhere — all of these are well-formed JSON and all of them are the thing the published guidelines specifically prohibit. The consequence is not usually a dramatic penalty; it is that the markup gets ignored, which makes the whole exercise a waste of an afternoon.
So the working order is: put the content on the page first, then describe it. Not the other way round.
Honest expectations
It is worth being blunt here because the topic attracts confident claims. Structured data does not cause a page to rank. It does not guarantee a rich result — the star ratings, the FAQ accordions, the recipe cards. Those are granted at each search engine's discretion, they are turned on and off for whole categories from time to time without warning, and eligibility criteria are revised regularly. FAQ rich results in particular were widely shown, then sharply restricted, and pages that had added the markup for that reason got nothing for it.
What markup reliably does is make your content legible to anything that parses pages rather than reading them, and that set is larger than search engines. If that seems like a thin return, it is a fair reading, and it is a better basis for deciding than a promise of traffic.
Validating it
This tool builds an object and serialises it, so the output is always syntactically valid JSON — you cannot get a trailing comma or an unescaped quote out of it. That is a smaller guarantee than it sounds. Valid JSON can still use a property that does not exist on the type, a type that does not exist at all, or a date in a format nothing will parse. Two separate things are worth running after you paste: the schema.org vocabulary validator, which checks your properties against the vocabulary, and whatever the search engine you care about publishes for testing its own requirements, which are stricter and different. Neither is this page, and neither can be, since both need to fetch the live URL.
Dates, currencies and the small formats
Dates should be ISO 8601: 2026-02-14, or with a time and an offset when the time matters. Currency is the three-letter ISO 4217 code, so USD, not a dollar sign. Availability is a full URL into the schema.org vocabulary — https://schema.org/InStock — rather than the bare word, which is a common and silent mistake. Prices are written as a string with a plain decimal point and no thousands separator and no symbol.
Once the block is in place, the tags that sit alongside it are covered by the meta tag generator for title, description and Open Graph, and the canonical and robots tag builder for indexing directives. If the JSON needs reformatting or diffing later, the JSON formatter handles that, and the JSON diff will show what changed between two versions of a block.
Questions people ask
Will adding this make my page rank higher?
No, and be sceptical of anyone who says otherwise. Structured data describes a page; it is not a ranking input you can turn up. The plausible mechanism people have in mind is a rich result attracting more clicks, and rich results are discretionary, revocable and often withheld from pages whose markup is perfect. Add it because a machine-readable description is useful, not as an investment with an expected return.
Can I mark up content that is not visible on the page?
No. That is the one rule the published guidelines are explicit about, and the usual outcome is that the markup is disregarded entirely. If you want FAQ markup, put the questions and answers on the page where a reader can see them, then describe them here.
Head or body?
Either. JSON-LD is not positional and nothing about it depends on where the block sits, so put it wherever your template makes it easiest to generate correctly. What does matter is that it appears in the HTML your server returns. Anything that parses your page without executing JavaScript will not see a block that a script inserted afterwards.
Can one page carry several blocks?
Yes, and it is normal. A product page might carry a Product block, a BreadcrumbList and an Organization block. You can also combine them into one graph with @graph, but separate script tags are easier to generate and easier to read when something goes wrong. There is no benefit to cramming them together.
Why does the tool say my markup is valid when a validator disagrees?
Because they check different things. This page guarantees the output is valid JSON — it builds an object and serialises it, so the syntax cannot be wrong. It does not check your property names against the schema.org vocabulary, and it cannot check a search engine's own eligibility rules, which are stricter and change. A validator that fetches the live URL is doing a job this page structurally cannot do.