Creating an Open Graph image URL means adding an og:image meta tag with an absolute HTTP or HTTPS address that points to a publicly reachable image, placed in the HTML head of the canonical page. The Open Graph Protocol defines four required properties — og:title, og:type, og:image, and og:url — and the image value is the single piece that drives how a share preview looks before any text is read. The URL itself does not upload or host the image; it points crawlers to a file your server already serves, so the entire responsibility of hosting sits with your infrastructure rather than with the metadata. That separation is why Open Graph image URLs fail so often in practice: the meta tag looks syntactically correct in the source, but the file it points to cannot be fetched, uses the wrong format, or is hidden behind authentication or a robots exclusion. Producing og:image therefore has two halves: writing the meta element with valid syntax that survives HTML escaping, and confirming the URL resolves to an image a sharing crawler can actually read at request time.
What the og:image URL Actually Controls
Open Graph metadata only describes a page; it never replaces the file it references. The og:image value is an instruction that tells a sharing crawler, "when you see this URL shared, fetch this image and use it as the preview picture." The crawler is responsible for resolving the link, downloading the file, validating the format and dimensions against the platform's rules, and applying its own cropping or caching decisions. None of that is your responsibility when you write the tag, but all of it determines whether the preview looks the way you intended.
What you do control by writing the meta tag is whether the file is reachable from the crawler's vantage point. That vantage point is almost always a public data-center IP, never a logged-in browser, so any path that depends on cookies, sessions, geographic restrictions, or rate-limited CDN rules will simply fail. The protocol treats og:image as a single scalar value — there is no array, no fallback chain, no remote picture element. Many sharing systems do silently pick the first og:image they find when multiple are declared, but the protocol itself only defines one image value per object. Writing the tag well therefore means producing one correct URL, not several hopeful ones.
URL and Image Requirements for a Sharable Preview
The Open Graph Protocol, as documented at ogp.me, leaves the format of the image itself unspecified beyond noting that it must be a "representative image," which is why every sharing service publishes its own technical rules. What the protocol does enforce at the URL level is strict: the value must be absolute, use http or https, contain no fragment, and contain no user credentials. The Open Graph Generator follows these rules at runtime by normalizing browser-parsed URLs and rejecting anything that does not match that shape, which keeps the meta output auditable instead of silently producing a tag that crawlers refuse to fetch.
The four required properties must be present together; the generator emits og:title, og:type, og:image, and og:url in that stable order, then appends any optional og:description, og:site_name and og:locale that pass validation. Optional values are bounded, trimmed, control-character rejected, and HTML-escaped on the way into the meta element, so ampersands, quotes, and angle brackets in titles or descriptions cannot break the generated tag. The optional locale is intentionally conservative — it accepts only a two-letter language and two-letter territory such as en_US, because broader alternates require additional protocol properties and editorial decisions beyond a single-block generator.
| Property | Required? | Stable order | Notes |
|---|---|---|---|
| og:title | Yes | 1 | Object name; rendered as an escaped HTML attribute |
| og:type | Yes | 2 | Restricted to "website" or "article" by this generator |
| og:image | Yes | 3 | Absolute HTTP(S) image URL, no fragment, no credentials |
| og:url | Yes | 4 | Canonical page URL, fragment-free |
| og:description | No | 5 | Optional summary; length-bounded and escaped |
| og:site_name | No | 6 | Optional brand or publication name |
| og:locale | No | 7 | Optional language_TERRITORY such as en_US |
The image URL field rejects any value that does not match the accepted shape. The shape is intentionally narrow so that every meta element produced by the form is something a crawler has a reasonable chance of fetching without further inspection.
| Image URL input | Accepted? | Reason |
|---|---|---|
| https://cdn.example.com/cover.jpg | Yes | Absolute, HTTPS, no fragment, no credentials |
| http://example.com/banner.png | Yes | Plain HTTP is permitted; HTTPS is preferred where available |
| https://example.com/post#hero | No | Fragment splits shares of the same resource into separate cache keys |
| https://user:[email protected]/hero.jpg | No | Embedded credentials can leak into public metadata |
| data:image/png;base64,... | No | Non-HTTP scheme; no crawler can fetch a data URI |
| /uploads/cover.jpg | No | Relative URL is normalized or rejected; absolute is required |
Generate the og:image URL and the Rest of the Block
- Open the Open Graph Generator in your browser; all processing happens client-side and no URL is fetched.
- Enter the title as it should appear in a share preview, using the exact wording you want crawlers to see.
- Choose either "website" or "article" from the object type select; richer protocol types are out of scope for this focused form.
- Paste the canonical page URL — absolute HTTP or HTTPS, with no fragment and no embedded credentials — into the URL field.
- Paste the og:image URL into the image field using the same shape: absolute HTTP or HTTPS, pointing to a public file, no fragment.
- Optionally add a description, a site name, and a locale in language_TERRITORY form such as en_US; these fields are bounded and trimmed.
- Generate the block; the four required properties appear in og:title, og:type, og:image, og:url order, then any valid optional fields.
- Copy the protocol-only block and paste it inside the <head> element of the canonical page, as plain HTML rather than visible text.
- Inspect the rendered source and run each target platform's preview debugger to confirm the image URL resolves, dimensions pass, and the cache reflects the latest values.
Internal validation guards the form against the inputs that cause most production failures. The object type select is rechecked at runtime, the page and image addresses are normalized to be fragment-free and credential-free, optional text is bounded and checked for control characters, and every attribute value is HTML-escaped so ampersands, quotes, and angle brackets cannot break the resulting meta element. The output follows Open Graph property syntax rather than the older name syntax documented for general meta tags, which is what sharing crawlers expect to find.
Where the Open Graph Block Goes in Your HTML
Open Graph meta elements belong inside the <head> element of the canonical page. The standard <meta> element uses property and content attributes, and the output from the generator follows that property syntax, not the older name form used by <meta name="description">. Putting the tags in the body, in template footer partials, or as visible page text defeats the purpose: crawlers specifically look for these tags in the head before rendering, as defined in the WHATWG HTML specification for the meta element.
The block should appear exactly once. Adding the same tags through both a framework and a plugin will produce duplicate meta elements, and most sharing services treat duplicate property declarations as "last one wins" or simply ignore the conflict. Build tools that reorder or rewrite the head can also overwrite an og:image you placed manually, so after a build runs, view-source on the canonical URL and confirm the order and the four required values are still present. Escaping matters when you paste: the generator already escapes each attribute value for HTML, so the block can be dropped into the head without further encoding. Re-encoding the whole block — running the meta lines through another escaping pass — will mangle valid characters.
Common og:image URL Mistakes That Break Previews
Several failures repeat across sites even when the meta tag itself is syntactically correct. The first is pointing og:image at a host or path the crawler cannot reach. Internal hostnames, staging URLs, and IP addresses often resolve from the editor's browser but not from a sharing data center; sharing services will silently fall back to a missing-image placeholder. The cure is to publish the image on the production CDN before the canonical page goes live and to test the URL from outside the office network.
The second is the wrong format or dimension. PNG, JPEG, and WebP cover almost every platform, but each platform imposes minimum and maximum pixel sizes, byte limits, and aspect ratios that the protocol does not define. A 1200-by-630 PNG sits comfortably inside the common landscape crop, while a 200-by-200 square will be rejected or stretched. The generator does not verify dimensions or MIME types because it has no way to fetch the image; that check belongs in your own pipeline before the URL is fixed.
The third is the cache effect. Sharing services cache the preview of a URL based on the URL itself, not on the meta tags, so changing og:image on the same canonical URL does not automatically change the preview. Each platform publishes a debugger or share inspector that re-fetches the page and clears the cached representation; using it is the only reliable way to force a refresh. Treat the canonical URL as the cache key: if you ever need a different preview, change the canonical URL, not just the og:image value.
Verify Each Preview on the Target Platforms
After the block is in the head and the page is reachable, the work of producing Open Graph previews shifts from authoring to verification. Every platform you target — major social networks, professional networks, messaging apps — applies its own image rules, fetches through its own data centers, and maintains its own cache. Each one publishes a debugger that lets a logged-in developer paste the canonical URL and inspect what the crawler saw: the rendered title, the resolved image URL, the byte size, the dimensions, and any error or warning.
Run the canonical URL through each debugger after the page is live and after any change to the og:image value. Compare the title, description, and image that the debugger reports against what you intended. If the rendered image is the previous version, the platform is serving a cached copy and the debugger usually exposes a "fetch again" or "clear cache" action; trigger it and recheck. If the title is missing or different, your head emitted a duplicate or a competing tag from a framework; view-source the URL and reconcile. If the image URL is rejected, return to the URL rules above and confirm the scheme, host, file format, and accessibility.
A valid Open Graph block does not guarantee how a post appears. Sharing systems can crop images, truncate text, ignore fields, choose cached data, or apply account-level policies that no tool can predict. Treat the metadata as accurate source content for those systems rather than as a layout contract. Write metadata that matches the visible content of the page, because a misleading title, description, or image can disappoint visitors and undermine trust even if it earns a click.
Building an og:image tag that actually renders is a function of two separate checks. The syntax must come from a generator that enforces the four required properties, renders attribute values as escaped HTML, and refuses to emit an incomplete block. The URL it produces must point at a public, properly sized image that the sharing crawlers can fetch from their own data centers. The Open Graph Generator handles the first half, and the platform debuggers close the loop on the second. Produce the block, paste it into the head of the canonical page, and verify the rendered share preview on every channel you actually publish to.