An Open Graph Generator on Windows creates the four required Open Graph properties in a browser and provides a protocol-only block to copy into the canonical page head.
Optional description, site name and locale are supported, but the tool does not fetch the submitted URLs, create Twitter Card tags, or guarantee how a social platform will display the page.

What the Windows workflow creates
The form covers the page fields needed for a shareable graph object: a title, an object type, the canonical page URL, and a representative image URL. You can also add a description, the larger site name, and a locale. The Open Graph Protocol identifies four basic properties as required, and the generator always emits them first.
| Property | Status | Purpose |
|---|---|---|
| og:title | Required | Names the shared object. |
| og:type | Required | Classifies the object as a website or article in this generator. |
| og:image | Required | Provides a URL for a representative visual. |
| og:url | Required | Identifies the permanent canonical object. |
| og:description | Optional | Summarizes the object. |
| og:site_name | Optional | Names the larger site. |
| og:locale | Optional | Uses language_TERRITORY form, such as en_US. |
Output uses property syntax such as <meta property="og:title" content="..."> rather than name syntax. The generator preserves a stable property order, trims entered text, applies length bounds, rejects control characters, and escapes attribute values. Ampersands, quotes and angle brackets therefore cannot break a generated element. The block contains Open Graph properties only; it does not contain Twitter Card tags.
Generate Open Graph tags in a Windows browser
- Open the Open Graph Generator in the browser on your Windows PC. All form processing and generation happen in the browser, so the workflow begins with a normal web page rather than a desktop setup.
- Enter a title that accurately names the page, then select website or article as the object type. These are the only types the form supports because richer protocol types need their own additional structured properties.
- Add the canonical page URL and representative image URL as absolute HTTP or HTTPS addresses intended to be publicly reachable. Do not include credentials or a fragment such as #section. The browser URL parser normalizes accepted addresses, but the tool does not fetch them.
- Optionally enter a description, site name and locale. Locale uses language_TERRITORY form, such as en_US; the validator accepts a conservative two-letter language plus a two-letter territory. Alternate locales and script subtags fall outside this focused form.
- Generate the metadata. If any required value is missing, output is blocked rather than producing an incomplete block. With valid input, copy the protocol-only block; the required properties appear first, followed by any optional fields you supplied.
- Open the source that controls the canonical page in your Windows editor or publishing system, then paste the block into the HTML <head>. Save the change and publish or deploy it using your normal site workflow.
- Inspect the delivered page source after deployment, then use the current preview debugger for every social service you target. Follow the verification steps below because successful generation does not prove crawler access or a refreshed preview.
Place the block in the canonical page head
Open Graph metadata belongs in the HTML head of the page identified by og:url. The HTML meta element specification explains why these elements belong in the document metadata rather than in visible body content. Paste the generated elements as they appear: do not encode the entire block a second time and do not show it as page text.
Before saving, check how your site produces its final head. A framework, template, plugin or deployment script may already add Open Graph elements. Avoid maintaining the same tags through both a plugin and a hand-edited template. Duplicates can leave conflicting values in the response, while a build step can reorder or overwrite what you pasted.
- Keep one generated Open Graph block for the canonical page.
- Make the title, description and image match the visible content so the preview does not misrepresent the destination.
- Check the delivered HTML instead of assuming the editor preview reflects production.
- Update the metadata, image and page representations together if the page moves or changes identity.
Verify delivered source and platform previews
After publishing, inspect the response a crawler receives and confirm that all four required properties are present once, along with any intended optional properties. The generator validates the values supplied to it, but it cannot report the final HTML produced by your build process.
- Compare the raw delivered source with the copied block. Look for missing elements, duplicate properties, rewritten URLs or later tags that conflict with the generated values.
- Confirm that the canonical page can be accessed by the target service's crawler and that the image URL points to a publicly reachable image. Keep that access stable after publication.
- Check the fetched image response and platform requirements separately. The generator does not test HTTP status, MIME type, dimensions, byte size, aspect ratio, redirects, robots controls or authentication.
- Open each target platform's current debugger or share inspector, then request a preview using the published URL.
- If the preview displays old information, account for that platform's cache refresh behavior and test again. A valid block can still produce a stale card.
- Compare the raw source, fetched image and live platform preview together. Update all representations consistently when any part of the page or image changes.
Even with valid metadata, social services can crop images, truncate text, ignore fields, show cached data or apply account-level policies. The current debugger for each service is the relevant check; the generator cannot promise a particular card layout.
Understand the validation boundary
The generator is deliberately narrow. It creates a protocol-shaped Open Graph block for two object types, not a universal social metadata package. The following comparison separates what the tool validates from what the publisher must still confirm.
| Area | Generator behavior | Publisher check |
|---|---|---|
| Object type | Accepts website or article and checks the selection again at generation time. | Use a specialized implementation for richer types. |
| URLs | Requires absolute HTTP or HTTPS values without credentials or fragments and normalizes accepted values. | Check reachability, crawler access, redirects and the image response. |
| Text | Trims input, bounds length, rejects control characters and escapes HTML attributes. | Confirm accuracy against the visible page and platform limits. |
| Locale | Accepts one conservative language_TERRITORY value. | Add alternate locales or script subtags through broader protocol work and editorial decisions. |
| Output | Emits the required properties first in stable property syntax. | Confirm that the build process has not altered or duplicated the block. |
| Preview | Produces protocol metadata only. | Verify platform caches, rendering and service-specific tags. |
Because neither URL is fetched, successful generation is not proof that either resource is available. If a social crawler cannot retrieve the page or image, the preview can fail regardless of valid markup. If the page needs a music, video, profile or another richer object type, use an implementation that collects the extra fields required for that type.
Open Graph is also not interchangeable with every platform's native format. Some services can use Open Graph properties as fallbacks, but Twitter Card metadata and other service-specific rules remain separate. Keeping those tags separate from the generated Open Graph block makes each protocol independently auditable and avoids presenting a service-specific field as a universal requirement.
If you're weighing options, Extract URLs From Sitemap on Windows: XML to URL List covers this in detail.
If you're weighing options, How Do I Decide If I Need to Generate a Canonical Tag? covers this in detail.