Enter your business details once and this generates a single connected @graph containing Organization, LocalBusiness and Service nodes, each with a stable @id, cross-referenced to each other, with a sameAs block and a WebSite node. Copy it into the head of your page. Everything runs in your browser.
This generator maps the fields you enter onto schema.org types and emits a single @graph with @id cross-references between the nodes. It validates presence and basic shape of required and recommended properties. It does not crawl your site, and it cannot verify that anything you typed is true.
JSON-LD is a block of structured data that states, in a machine-readable vocabulary, what a page is about. It sits inside a script tag with type application/ld+json, normally in the head of the document, and it is invisible to human visitors. It is the preferred format over microdata and RDFa for one practical reason: it is separate from your markup. You can change your entire design without touching the structured data, and you can change the structured data without touching a template. Placement is straightforward. One block per page, in the head, describing that page and the entity behind it. If your site is server-rendered, put it in the template. If it is client-rendered, make sure the block is present in the initial HTML response rather than injected after hydration, because not every consumer executes JavaScript.
Because separate blocks describe separate things, and your business is one thing with parts. The common pattern of pasting an Organization block, then a LocalBusiness block, then a Service block, produces three descriptions with no stated relationship between them. A parser has to guess whether the LocalBusiness is the same entity as the Organization, and whether the Service is offered by either of them. Guessing is exactly what structured data exists to eliminate. A single @graph with @id cross-references states the relationships explicitly. The Organization has an @id. The LocalBusiness references it as its parentOrganization. Each Service references it as its provider. The WebSite references it as its publisher. Now there is one entity with a physical location, a website and a set of services, and nothing has been inferred. This matters more for answer engines than for classic search, because an answer engine has to resolve you to one entity before it can attribute a claim to you.
As URLs you control, with a fragment identifier, and they must never change. The convention this generator follows is your canonical site URL plus a fragment naming the node: the Organization is at yoursite.com/#organization, the LocalBusiness at yoursite.com/#localbusiness, the WebSite at yoursite.com/#website, and each Service at its own page URL plus #service. Two rules matter more than the convention itself. First, an @id must be globally unique, which a URL on a domain you own automatically is. Second, it must be stable, because the whole point of an identifier is that references to it keep resolving. If you restructure your site, keep the @id values pointing at the same conceptual thing even if the page moved. The fragment is doing real work here. Without it, your Organization @id would be the page URL itself, which collides with the WebPage that lives at that URL. The fragment separates the entity from the document that describes it.
sameAs is an array of URLs pointing at other authoritative representations of the same entity. It is how you tell a parser that the business described here is the same business as the one on that LinkedIn page and that Google Business Profile. List profiles you actually control and actively maintain: your Google Business Profile, LinkedIn company page, the primary social accounts you post from, Crunchbase if you have an entry, and any industry registry or licensing body that lists you. If your business is notable enough to have a Wikipedia or Wikidata entry, those are the strongest entries in the array by some distance. Do not pad it. A sameAs array containing fifteen abandoned social profiles and four directory listings you have never updated is weaker than one containing four accurate, current URLs. Every entry is a claim of identity, and one that resolves to a stale or contradictory profile actively undermines the entity resolution you were trying to strengthen.
Because self-serving review markup is a policy risk, and because on most sites it is simply untrue. Review and AggregateRating properties added by the business about itself, rather than derived from verified collected reviews, are exactly the pattern search platforms treat as spam. The upside is a star rating in a result. The downside is a manual action against the whole domain. The more important reason is honesty. A generator that offers an AggregateRating field is inviting you to type a number, and there is no mechanism anywhere in the pipeline that checks whether that number came from real reviews or from optimism. This site was recently cleaned of invented statistics, including a satisfaction score nobody had measured, and shipping a tool that makes it easy for other people to do the same thing would be difficult to defend. If you have genuinely collected verified reviews, mark them up from the review platform's own integration, where the data has a provenance you can point at.
If you have a physical location customers visit, yes, and they should be connected: the LocalBusiness references the Organization as its parentOrganization. If you have no physical presence, emit Organization only. A LocalBusiness without a postal address is worse than none.
In a script tag with type application/ld+json in the head of the page. It must be present in the initial HTML response, not injected after hydration, because not every consumer executes JavaScript.
A URL you control plus a fragment, such as yoursite.com/#organization. Unique because you own the domain, stable because you never change it, and separated from the document URL by the fragment.
Not directly. It removes ambiguity about what a page is and which entity published it. That makes you easier to include in an answer, but it does not make the page worth including.