Set the image in your page’s HTML <head> with an og:image meta tag, alongside og:title, og:type and og:url. Add og:image:alt to describe the image, then inspect the rendered source to confirm the tags are present. This is the protocol-level implementation; an og:image tag alone is not a verified guarantee of any particular current X card layout.
What an Open Graph image is
An Open Graph image is a URL in your webpage metadata. It is not an image attachment uploaded to an X post. Social crawlers can read the metadata when they fetch the page and use it to represent the page in a link preview. The Open Graph protocol specification defines the basic properties and places them in the document head.
For a page to implement the basic protocol, provide these properties:
| Property | Purpose | What to enter |
|---|---|---|
og:title |
The page or object title | A page-specific title |
og:type |
The object type | Usually website for a normal site page |
og:url |
The canonical URL of the object | The URL you want represented |
og:image |
The representative image | A URL to the image file |
Use a complete, publicly retrievable image URL in production. Keep the image associated with the page it represents, and make sure the server returns the image rather than an HTML error page.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
Add the tags to the page head
Place the tags between <head> and </head>. Replace every example value with data for the specific page:
<head>
<meta property="og:title" content="Page title">
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/page">
<meta property="og:image" content="https://example.com/images/share-image.jpg">
<meta property="og:image:alt" content="Description of the image">
</head>The property names use the property attribute and the value goes in content. A tag placed in the visible body, in a stylesheet, or only in JavaScript is not the protocol pattern shown by the specification.
Describe and extend the image
The specification defines structured image properties. og:image:url is equivalent to og:image; the other properties provide additional information:
og:image:secure_urlsupplies a secure alternative URL.og:image:typeidentifies the image media type.og:image:widthandog:image:heightgive the image dimensions.og:image:altdescribes what is in the image. It is an image description, not a caption printed over the picture.
The protocol says that when a page specifies og:image, it should also specify og:image:alt. Write concise, meaningful alternative text, such as “Blue dashboard showing monthly revenue,” rather than repeating a file name.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →When a page has more than one image
Open Graph properties can be repeated. The specification gives the first value, from top to bottom, preference when values conflict. Put the preferred image first:
<meta property="og:image" content="https://example.com/images/primary.jpg">
<meta property="og:image:alt" content="Primary product photo on a white background">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image" content="https://example.com/images/secondary.jpg">
<meta property="og:image:alt" content="Product detail close-up">Keep each image’s structured properties immediately after its root og:image declaration and before the next root image. Otherwise, a consumer may associate dimensions or alternative text with the wrong image.
Choose an implementation route
| Route | Best when | Required check |
|---|---|---|
| Edit the page template or HTML directly | You control the site code and can create page-specific values | View the rendered document source and verify the final head |
| Use a CMS or publishing plugin | Editors need fields for social metadata without editing templates | Confirm that the CMS actually emits the expected property tags in the rendered head |
A CMS setting is only useful if it produces metadata in the response that a crawler receives. Do not assume that entering an image in an editor is equivalent to emitting og:image; inspect the page source after publishing.
Publish and verify the metadata
- Upload the image at the URL used in
og:image. - Open the page in a browser, choose “View page source” (not only the live DOM inspector), and search for
og:image. - Check that
og:title,og:type,og:url,og:imageandog:image:altare present once for the primary object, unless you intentionally provide multiple images. - Copy the image URL into a new browser tab and confirm that it returns the intended file without an access prompt or redirect to an error page.
- Share the page in a controlled test and inspect the resulting preview. Treat this as practical verification of the live page, not as proof of a permanent X-specific rule.
Use the canonical URL in og:url, keep metadata values specific to each page, and publish the image before publishing the page that references it. If your application renders metadata server-side, verify the raw HTML response; a tag inserted only after client-side JavaScript runs may not be available to every crawler.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWhy the image is not showing on X
The available X Developer result at developer.x.com/en/docs/tweets/data-dictionary is a legacy API data dictionary. It does not establish current page-head Cards markup, image constraints, card variants, precedence rules, preview tools, or cache-refresh procedures. Therefore, do not treat older tutorials about twitter:* tags, fixed pixel sizes, or a particular card type as verified current X behavior.
Use this troubleshooting order without assuming that any one fix guarantees a specific X card:
The tag is missing from the response
Inspect the raw page source. If the metadata exists only in a CMS editor, template variable, or client-side DOM after JavaScript execution, configure the template or server-rendered head so the final HTML contains the tags.
The URL points to the wrong resource
Open the exact og:image URL directly. Correct a typo, redirect loop, authentication requirement, or response that returns an HTML error page instead of an image.
The wrong image wins
Search for every og:image declaration. Because the protocol gives the first value preference, move the intended image and its structured properties above alternatives, or remove duplicate tags generated by a theme and a plugin.
The page has an image but no description
Add og:image:alt and describe the visual content. Keep the description factual and page-specific.
A preview still does not appear
Recheck the published URL, the raw head, and the image response, then try a new share test. X-specific fetching, caching and accepted markup can change independently of the Open Graph protocol. The available sources do not verify a current X debugger workflow or a guaranteed refresh command, so avoid promising that a particular tool or tag will force an update.
Do you need a twitter:image tag?
The protocol-level implementation above uses og:image. The current X-specific requirement and precedence between Open Graph and any X-namespaced image tag are not established by the available authoritative material. Implement the documented Open Graph fields first, inspect the rendered head, and consult a current X Cards specification before adding platform-specific tags or relying on them.
Performance, reliability and security considerations
- Serve a stable image URL and avoid generating a different file on every request unless you also update the metadata.
- Keep the image on infrastructure that can respond to an unauthenticated crawler request; a private bucket or expiring URL can prevent retrieval.
- Use an appropriate image format and file size for your site’s performance budget, but do not infer an X-required format or dimension from this guide.
- Escape quotes and special characters in
contentvalues. A malformed attribute can hide later tags from parsers. - When changing an image, change the URL or otherwise follow your platform’s documented cache controls. The available X material does not establish a universal cache invalidation method.
- Do not place secrets, signed credentials, or personal data in a public image URL or in metadata that every crawler can read.
FAQ
Can the same Open Graph image be used on every page?
Yes, the protocol permits a shared representative image, but page-specific imagery usually communicates the destination more clearly. Whichever approach you choose, keep the image URL and alternative text intentional for each page.
Is og:image:url different from og:image?
The Open Graph specification describes og:image:url as equivalent to og:image. Use one root declaration per image and add structured properties beneath it.
Does adding metadata change an image already embedded in an X post?
No conclusion about an already-published post can be made from the Open Graph specification. Metadata describes the webpage fetched for a link; any behavior for an existing X post depends on X’s current implementation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Or skip the browser setup
If you need a clean screenshot of the published page while checking its metadata, ScreenshotNeo provides a website screenshot API and MCP server. It accepts one GET request and returns a PNG, JPEG, WebP or PDF. Its cleanup steps accept cookie-consent banners and remove more than 60 known consent platforms, newsletter popups and chat widgets before capture; each step can be disabled.
Here are complete requests (the API documentation is at screenshotneo.com/docs/):
Best Value
cURL
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/page -o shot.webpPython
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://example.com/page"}, timeout=90)
open("shot.webp", "wb").write(r.content)Node.js
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com/page' }); const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);ScreenshotNeo bills only clean shots. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads and cache hits cost nothing, and each response identifies the result with X-Page-Verdict and X-Billed headers. Its MCP server includes take_screenshot, get_page_info and capture_pdf tools for Claude, Cursor and other MCP clients.
The Free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 shots; every feature is included on every plan. Create a free ScreenshotNeo account to try it without entering a card.
Frequently Asked Questions
Can an Open Graph image URL contain query parameters?
The protocol describes an image URL, so query parameters are syntactically possible. Keep the resulting URL stable and publicly retrievable, and verify that it returns the image rather than a redirect or error document.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesShould metadata be different for a canonical URL and its tracking-parameter variants?
Use the canonical page address in og:url and generate the same page-specific metadata for equivalent URL variants. This keeps the represented object consistent.
Where can I find the current X-specific card rules?
Use X’s current developer documentation when it is available. The legacy data-dictionary page at developer.x.com/en/docs/tweets/data-dictionary does not define current page-head Cards markup.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
