How to Fix an Open Graph Image That’s Too Small to Display
Fix small social previews by checking your og:image URL, dimensions, tag order, and crawler access, then refresh the preview in the platform inspector.
If an Open Graph image appears too small in a social preview, first check the exact image URL in the page’s <head>, confirm the file’s real pixel dimensions, and make sure an earlier og:image tag does not point to a smaller asset. For a broadly useful landscape preview, prepare an image around 1200 × 630 pixels (about 1.91:1), make it publicly fetchable, and then refresh the preview in the platform’s inspector.
Image dimensions are only one possible cause. The platform may be selecting a different image, unable to fetch the image, or showing cached preview data. Use the checks below to distinguish those cases.
1. Inspect the Open Graph tags delivered in the page head
Open the page’s HTML source or inspect the HTML response delivered to crawlers. Confirm that the page has an og:image property and that its content is an absolute URL to the intended image. The Open Graph protocol defines og:image as a basic property and says that when multiple images are declared, the first is preferred in conflicts.
<head>
<meta property="og:title" content="A useful page title">
<meta property="og:description" content="A concise description of the page.">
<meta property="og:image" content="https://example.com/images/article-share.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="A wide illustration of the article topic">
</head>
Use the actual width and height of the image in the structured properties. These values describe the asset; they do not enlarge a small image or replace the image file. The protocol also defines og:image:type and og:image:secure_url for image metadata where relevant. It recommends a descriptive og:image:alt.
Check for duplicate or generated tags
View the complete head and search for every og:image. A CMS theme, SEO plugin, template, or server-side renderer can add a tag in addition to one you set manually. Put the intended image first, remove conflicting duplicates where possible, and verify the final HTML response rather than relying only on the editor’s settings.
2. Measure the image file itself
Open the exact URL named by og:image and inspect the downloaded file’s pixel width, height, format, and file size. A large CSS display size or a high-resolution source elsewhere on the site does not help if the metadata points to a small thumbnail.
| Guidance | What it says | How to apply it |
|---|---|---|
| LinkedIn sharing module | At least 1200 × 627 pixels; 1.91:1 recommended ratio; maximum 5 MB. Images under 401 pixels wide display as thumbnails. | For LinkedIn, meet its stated minimum and file-size limit. See LinkedIn’s sharing guidance. |
| Facebook figures reported by Wix | 1200 × 630 pixels recommended at 1.91:1; 200 × 200 pixels minimum; images below 600 × 315 pixels display as small previews. | These are Wix’s summary of Facebook Sharing Best Practices, not a direct Meta source. See Wix’s guide. |
A 1200 × 630 landscape image is a practical shared target for many wide previews, but platforms may crop or render images differently. If LinkedIn is important, its published minimum is 1200 × 627 pixels. Keep the subject away from the extreme edges so a crop is less likely to cut it off, and check the result in each target platform.
3. Check that crawlers can fetch the image
The image URL must be reachable by the platform that generates the preview. Open it without being signed in and confirm that it returns the image itself. Check for access controls, hotlink restrictions, redirects to a login page, or a protected directory. LinkedIn notes that blocking its crawler or storing the image in a protected location can prevent an otherwise qualifying image from appearing.
Do not assume the page and image have the same access behavior: a public page can reference an image that requires authentication. If the HTML is rendered client-side, also confirm that the crawler receives the relevant Open Graph tags in its HTML response.
4. Refresh and inspect the platform preview
- Deploy the corrected image or metadata.
- Submit the page URL to the inspector for the platform where the preview looks wrong.
- Review which image URL the inspector fetched, whether it reported a fetch or parse error, and what preview it produced.
- If it still shows an old image, verify the inspector is reading the updated page and image URL. A changed asset at the same URL may still be represented by cached preview data.
- Repeat for other target platforms; one platform’s result does not guarantee identical rendering elsewhere.
The Open Graph site identifies Facebook’s Object Debugger as its parser and debugger. Wix also recommends Facebook’s debugger after image updates. LinkedIn refers users to its Post Inspector.
5. Troubleshoot common causes
| Symptom | Likely cause to check | Fix |
|---|---|---|
| Preview is consistently tiny | The metadata points to a thumbnail or small derivative. | Change og:image to the full-size share image and confirm its actual pixel dimensions. |
| The wrong image appears | Another og:image appears first, or generated metadata overrides the intended value. |
Inspect the final head in document order and make the intended URL the first image value. |
| Image works in a browser but not in the inspector | The crawler may be blocked, redirected, or unable to access a protected image. | Check public access and the exact image response without a logged-in session; remove access restrictions that prevent the intended crawler from fetching it. |
| Image dimensions in tags look right but preview remains small | The width and height tags describe the image but do not change its actual size; alternatively, the platform may have selected another image. | Measure the file at the declared URL and inspect the fetched image URL in the platform tool. |
| Old preview remains after a change | The platform inspector or sharing service may be using previously fetched preview data. | Run the page through the platform’s inspector after deployment and review the newly fetched result. |
| Image is rejected or omitted on LinkedIn | It may fall below LinkedIn’s stated dimensions, exceed 5 MB, or be inaccessible to its crawler. | Meet the 1200 × 627 minimum, stay within the 5 MB maximum, and confirm public fetchability. |
6. Example checks with command-line tools
These checks help confirm what your server returns. They do not replace the target platform’s inspector, which shows what that platform parsed.
Fetch the page response
curl -L -sS https://example.com/article -o page.html
rg -n -i 'og:image|og:image:width|og:image:height|og:image:alt' page.html
Check the final document for duplicate tags and verify the image URL matches the asset you intend to share. If the HTML is produced dynamically, fetch the production URL as a crawler would receive it and inspect that response.
Fetch the image and inspect its dimensions
curl -L -sS -D image-headers.txt \
https://example.com/images/article-share.jpg \
-o article-share.jpg
file article-share.jpg
file often reports the image format and dimensions. If it is unavailable, use an image viewer or an image-processing utility already in your environment. Review the response headers and final response after redirects; make sure the downloaded bytes are an image rather than an error page.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. It can capture a page as PNG, JPEG, WebP, or PDF, which is useful for checking how a page appears after you fix its metadata. A screenshot shows the rendered page; use the social platform’s inspector to verify the Open Graph image it selected.
One GET request returns a screenshot. See the ScreenshotNeo API documentation for request options.
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://example.com/article \
-o shot.webp
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://example.com/article"},
timeout=90,
)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({
access_key: 'YOUR_API_KEY',
url: 'https://example.com/article'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));
- Cookie and consent banners, newsletter popups, and chat widgets can be removed before capture; each cleanup step can be turned off.
- Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed. Response headers report the page verdict and billing status.
- An MCP server provides
take_screenshot,get_page_info, andcapture_pdftools 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 screenshots; all features are available on every plan.
Sign up for ScreenshotNeo and get 1,000 free screenshots a month with no card.
Performance, reliability, and cost notes
- Performance: Use a suitably sized source image rather than an unnecessarily huge file, while still meeting the target platform’s dimensions and file-size guidance. For LinkedIn, the stated maximum is 5 MB.
- Reliability: Treat the final platform preview as the confirmation step. A correct local file and correct metadata do not establish that a remote crawler can fetch the asset.
- Cost: Fixing page metadata and replacing an image does not require a screenshot API. If you also need repeatable rendered-page captures, ScreenshotNeo’s Free plan includes 1,000 shots monthly; paid tiers begin at $5 for 3,000.
FAQ
Do og:image:width and og:image:height resize the image?
No. They describe the image. Replace or regenerate the actual file if its pixel dimensions are too small.
Is 1200 × 630 guaranteed to look the same on every platform?
No. It is a practical landscape target, while platforms have their own requirements and may crop or render previews differently.
Should I add more than one og:image?
You can declare multiple images, but the Open Graph protocol says the first is preferred in conflicts. Put the intended default first and verify the selected image in the platform inspector.


