Short answer: An Open Graph (OG) image is the representative image a webpage declares with og:image. When a social service reads your page, it can use that URL in the link preview. Add the core OG tags in your document head, use an absolute, publicly reachable image URL, describe the image with og:image:alt, and test the final URL on every destination that matters. There is no single crop or size that every service renders identically; LinkedIn’s sharing module, for example, specifies at least 1200 × 627 pixels and a maximum file size of 5 MB.
What an Open Graph image is
The Open Graph protocol lets a webpage declare how it should be represented when shared. Its image property is metadata: og:image contains the URL of an image representing the page or object. It is not a special image file format and it does not generate artwork for you. The Open Graph project describes the protocol this way: “The Open Graph protocol enables any web page to become a rich object in a social graph.”
The image is one part of a larger set of page-level properties. The basic object identity is supplied by og:title, og:type, og:url, and og:image. Each service decides which properties it reads, when it fetches them, and how it crops or lays out the resulting card.
The minimum metadata to add
Place the tags in the page’s <head>. Use the final canonical URL, not a relative path or a URL that only works inside your development environment.
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 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute#1 Best Overall
<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="A concise description of the image" />
Keep the text in each value accurate for the page. The og:url value is the object’s permanent graph identifier, so it should agree with the URL you want associated with shares. The image URL should be absolute and should return the image itself rather than an HTML error page, login screen, or redirect loop.
What each required property does
| Property | Purpose | Implementation check |
|---|---|---|
og:title |
The title associated with the shared object. | Match the page’s real subject; avoid leaving a template default. |
og:type |
Identifies the kind of object, such as a website. | Use the type that accurately describes the page. |
og:url |
The canonical graph identifier for the object. | Use one stable, absolute URL. |
og:image |
The URL of the representative image. | Make it publicly fetchable and point to the intended asset. |
og:image:alt |
A description of what is visible in the image. | Describe the image itself, not a marketing caption. |
Structured image properties
The protocol supports additional properties for an image. Add them when you can keep them synchronized with the actual file:
og:image:secure_urlcan identify the secure version of the image URL.og:image:typedeclares the image MIME type.og:image:widthandog:image:heightdeclare pixel dimensions.og:image:altsupplies the concise visual description required by the protocol.
For example:
<meta property="og:image" content="https://example.com/images/share-image.jpg" />
<meta property="og:image:secure_url" content="https://example.com/images/share-image.jpg" />
<meta property="og:image:type" content="image/jpeg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="627" />
<meta property="og:image:alt" content="A concise description of the image" />
Do not publish dimensions or a MIME type that differs from the file delivered by your server. Incorrect metadata can make debugging harder and may cause a consumer to reject or mis-handle the preview.
When you specify more than one image
Open Graph properties can be arrays. If several og:image tags are present, the first value in document order is preferred. Put your intended default first, then add alternatives only when you have a deliberate reason to do so. Inspect the rendered HTML—not just a template file—to confirm that another plugin has not inserted an unwanted image before yours.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsWhat size should an Open Graph image be?
There is no universal dimension proven by the available platform guidance. LinkedIn Help’s sharing module requires a maximum file size of 5 MB and minimum dimensions of 1200 pixels wide by 627 pixels high. Those figures are LinkedIn-specific requirements for that sharing module, not a guarantee that Facebook, X, Discord, or another service will use the same crop or card layout.
Rank #2
| Destination | Verified requirement in the available guidance | Practical action |
|---|---|---|
| LinkedIn sharing module | At least 1200 × 627 pixels; no more than 5 MB. | Prepare an image meeting both limits and validate a real shared URL. |
| Specific current dimensions were not established by the cited primary material. | Check current Facebook guidance and test the destination URL. | |
| X | Specific current dimensions were not established by the cited primary material. | Check current X guidance and test the destination URL. |
| Discord and other services | Preview behavior can differ; no common requirement is established here. | Use destination-specific checks rather than assuming one universal crop. |
A 1200 × 627 canvas is a sensible starting point when LinkedIn is important, but treat it as a baseline for that requirement rather than a promise about every network. Keep important text and logos away from edges so a destination crop is less likely to remove them. Use sufficient contrast and a concise visual message; these are design safeguards, not protocol requirements.
How platforms read and render your metadata
Services can read different subsets of your metadata and render different card layouts. A third-party platform guide documents differences among Facebook, X, LinkedIn, and Discord, but it is not a substitute for each platform’s current specification. A preview that looks correct in one debugger can therefore look different elsewhere.
- Choose the destinations that matter to your audience.
- Read each destination’s current, first-party sharing guidance before locking a crop or file limit.
- Share a real, publicly reachable URL on each destination.
- Check the image, title, URL, and crop independently; do not assume one successful preview proves all services will agree.
Keep a record of the URL tested and the version of the image deployed. This makes a later change distinguishable from a platform that has retained an older preview.
A complete do-it-yourself implementation
1. Create and publish the asset
Export one representative image for the page and publish it at a stable HTTPS URL. The server must return the image without authentication. Confirm that the URL works in a private browser window and that it does not depend on a session cookie.
2. Add the tags to the source
Insert the core tags in the document head. If your site uses a CMS, edit the page-level social metadata fields or the template responsible for the head; avoid adding duplicate sets through multiple plugins.
3. Add optional image details
Add secure URL, MIME type, width, height, and alt properties only when their values match the delivered file. The alt value should state what a person can see, such as “Blue pricing dashboard with three plan cards,” rather than “Click here to learn more.”
4. Verify the delivered HTML
View the deployed page source or fetch it as an unauthenticated client. Search for every og: property and check that the first og:image is intentional. A tag present only in a client-side component may not be available to a service that reads the initial HTML response.
5. Test each destination
Use the sharing or preview tool supplied by each important platform, then perform a real share when possible. Compare the result with the source image and note any crop, truncation, or stale value. Platform caches mean that changing the file at the same URL may not immediately change an already generated card.
Troubleshooting common failures
The preview has no image
- Cause: The
og:imageURL is relative, misspelled, blocked, or returns an error document. - Fix: Use an absolute HTTPS URL, open it without a session, and verify that the response is the actual image.
The wrong image appears
- Cause: Another
og:imageappears earlier in document order, or a CMS template inserted a default. - Fix: Inspect the final HTML and move the intended image to the first position or remove the unintended duplicate.
The image is cropped unexpectedly
- Cause: The destination uses its own card dimensions and crop rules.
- Fix: Test on that destination, keep critical content away from edges, and prepare a crop that satisfies its current guidance.
LinkedIn rejects the image
- Cause: The file exceeds 5 MB or is smaller than 1200 × 627 pixels for LinkedIn’s sharing module.
- Fix: Export an image meeting both limits, update the metadata if the URL changed, and test the deployed page again.
The old title or image persists
- Cause: The service retained an earlier preview.
- Fix: Confirm the current HTML and image first, then use the destination’s current preview-refresh process. Do not assume a universal cache-clearing command; procedures vary.
The alt text is misleading
- Cause: The value was written as a caption or call to action instead of a visual description.
- Fix: Rewrite
og:image:altto describe the visible subject and update it whenever the artwork changes.
Performance, reliability, and maintenance
- Keep the image at a stable URL when possible. Replacing the bytes behind the same URL can make cache behavior harder to reason about; versioned filenames make deployments easier to track.
- Optimize file size while staying within the destination’s limits. LinkedIn’s 5 MB ceiling is a concrete constraint when that sharing module is part of your distribution plan.
- Keep metadata generation deterministic. A page should not emit different OG values based on a logged-in user, a short-lived experiment, or a client-only script.
- Review the image whenever the page’s subject changes. An accurate title paired with an obsolete image is still a misleading preview.
- Re-test after changing redirects, canonical URLs, image hosting, consent tooling, or CMS plugins; each can alter what a crawler receives.
Or skip the browser setup
To inspect what a page actually renders, ScreenshotNeo is a website screenshot API and MCP server. It can capture a page after the browser accepts cookie or consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each cleanup step can be disabled. Only clean shots are billed: bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies the result with X-Page-Verdict and X-Billed headers.
Use the one-call API to capture a deployed page while checking its visual result:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/page -o shot.webp
See the parameter reference and all capture options in the ScreenshotNeo documentation.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Rank #4
Python
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}`);
For OG-image QA, relevant options include full-page capture with lazy images loaded, a CSS-selector element capture, 12 device presets or a custom viewport, retina scale, dark mode, custom CSS and JavaScript, clicking before capture, hiding selectors, waiting for a selector, delay, or network idle, and blocking ads, trackers, requests, or resource types. You can also supply headers, cookies, a user agent, Authorization, timezone, and geolocation; use those only when the page genuinely requires them.
For delivery workflows, ScreenshotNeo supports transparent backgrounds, image resizing, a chosen cache TTL, signed links for public <img> tags, asynchronous jobs with signed webhooks, bulk capture of up to 100 URLs per call, a usage API, an OpenAPI specification, and parameter names used by other screenshot APIs to ease migration. Its MCP server exposes take_screenshot, get_page_info, and capture_pdf tools to Claude, Cursor, and other MCP clients.
The Free plan includes 1,000 shots per month with no card. Paid plans start at $5 for 3,000 shots; yearly billing provides two months free, and every feature is available on every plan. Create a free ScreenshotNeo account to begin.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.FAQ
Is an OG image the same as a favicon?
No. A favicon identifies a site or page in browser interface elements, while og:image declares the representative image for a shared object.
Does adding OG tags change the page’s visible design?
No. These are head metadata elements. They influence how a consuming service represents the URL, not the content visitors see in the page body.
Best Value
Can I use one OG image for every page?
You can, but page-specific images usually communicate the destination more accurately. Whichever approach you choose, keep the declared title, URL, alt text, and image subject consistent.
Frequently Asked Questions
Is an OG image the same as a favicon?
No. A favicon identifies a site or page in browser interface elements, while og:image declares the representative image for a shared object.
Does adding OG tags change the page’s visible design?
No. These are head metadata elements. They influence how a consuming service represents the URL, not the content visitors see in the page body.
Free tools Windows power users keep installed
One-click scans. No signup required.
Can I use one OG image for every page?
You can, but page-specific images usually communicate the destination more accurately. Keep the declared title, URL, alt text, and image subject consistent.
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.

