BlogImage Compression

How to Compress Images for Open Graph and Social Sharing

Q: What size should an Open Graph image be?

A landscape image around 1200 × 630 px is a practical cross-platform starting point. LinkedIn specifically recommends 1200 × 627 px at 1.91:1. Keep important text and logos near the center and test each target platform because display containers can differ.

Q: Should I use WebP for `og:image`?

JPEG and PNG remain the conservative choices when one image must work across multiple social crawlers. Use WebP only after confirming current support and testing the resulting preview on every platform you target.

Q: What is the maximum file size for `og:image`?

The Open Graph protocol does not define a universal file-size limit. Individual platforms may publish their own limits; for example, LinkedIn documents a 5 MB maximum for its sharing module. Set a smaller internal performance budget and verify current platform documentation.

Q: How do I make a PNG Open Graph image smaller?

Start with lossless optimization, then use palette quantization if the result is still too large. OptiPNG recompresses PNG files without discarding information, while pngquant uses lossy color quantization and should be followed by a visual check.

Q: Can I use one social sharing image on every platform?

Usually, but no single canvas guarantees identical rendering everywhere. A 1.91:1 landscape image is a useful shared starting point; keep critical content inside a central safe area and validate the page on each priority platform.

Q: Why is my `og:image` not showing?

Check that the image URL is absolute, public, served over HTTPS, returns a successful HTTP status, and uses the correct image MIME type. Also inspect metadata order, crawler access, cached previews, and platform-specific requirements.

Q: Does compressing an Open Graph image improve page speed?

It reduces the bytes transferred when crawlers and preview clients fetch the image. It will not necessarily improve page-rendering metrics unless the same asset is also loaded as visible page content.

Learn how to resize, compress, and validate Open Graph images for clear, reliable social sharing previews.

July 29, 2026

Updated: July 29, 2026

To compress an image for Open Graph sharing, begin with a landscape canvas around 1200 × 630 px, choose JPEG for photographs or PNG for graphics with text, sharp edges, or transparency, and reduce the file incrementally while checking small text and logos at preview size. Publish the result at a public, absolute HTTPS URL with the correct MIME type, then validate the page on every social platform that matters to you. A few hundred kilobytes can be a useful internal performance target, but it is not a universal platform limit, and no single image size is guaranteed to avoid cropping in every client.

Key Takeaways

Use 1200 × 630 px as a common cross-platform starting point, not an inflexible rule.
Prefer JPEG for photo-heavy artwork and PNG for text, logos, flat colors, or transparency.
Distinguish lossless PNG optimization from lossy palette quantization.
Set a measurable byte budget, but check each platform's current documented limits separately.
Validate the deployed URL, metadata, MIME type, image order, and actual previews—not just the local file.

Why Open Graph Image Compression Matters

Social networks and messaging applications may fetch a page's metadata when a link is first shared, when a cached result expires, or when a refresh is requested. If the referenced image is inaccessible, unusually large, incorrectly labeled, or incompatible with the crawler, the resulting preview may omit the image or use an unintended fallback.

Compression helps by reducing transfer time and storage while preserving the elements that make the card recognizable. The useful question is therefore not “How small can this file become?” but “What is the smallest version that still renders the headline, logo, photograph, and colors correctly in the intended previews?”

The Open Graph protocol itself does not define image dimensions or a byte limit. It defines the metadata used to identify the image, including og:image, og:image:type, og:image:width, og:image:height, and og:image:alt. Platform-specific display rules sit on top of that protocol.

Open Graph Image Requirements by Platform

The following information was last checked on July 29, 2026. Platform behavior and documentation can change, so recheck the linked official sources before turning a recommendation into a build-time rule.

Consumer	Current useful guidance	What to verify
Open Graph Protocol	No universal dimensions or byte limit. The four basic properties are `og:title`, `og:type`, `og:image`, and `og:url`.	Confirm complete metadata and place structured image properties after their associated `og:image`.
Facebook	Uses Open Graph metadata for link sharing. Treat a 1.91:1 landscape canvas as a starting point and consult Meta's current sharing-image documentation for active limits.	Inspect the deployed page with Facebook Sharing Debugger and check the real desktop and mobile preview.
LinkedIn	The sharing module documents 1200 × 627 px, a 1.91:1 ratio, and a 5 MB maximum. Images below 401 px wide may display as thumbnails.	Test with LinkedIn Post Inspector and confirm that the image is publicly accessible.
X	Card documentation and tools have changed over time, so avoid relying on old format or file-size tables without rechecking them.	Include X Card metadata, use HTTPS, and confirm the result through the current official tool or a real test post.
Slack	Slackbot reads Open Graph and X Card tags, fetches referenced media for validation, and caches link-expansion responses for about 30 minutes.	Post the final URL in a test channel and allow for the documented cache interval before diagnosing a stale result.

A 1200 × 630 px canvas remains convenient for a shared asset because it is close to the 1.91:1 presentation used by several platforms. It does not guarantee identical rendering. If LinkedIn is the primary destination, use its documented 1200 × 627 px dimensions. In either case, keep essential text and logos away from the outer edges.

Choose the Right Format and Compression Method

JPEG, PNG, or a modern format?

Source artwork	Recommended starting format	Initial approach	Stop compressing when
Photograph or product shot	JPEG	Export around quality 80–85, then test lower settings gradually	Faces, gradients, or product edges show distracting artifacts
Text, logo, UI, or flat colors	PNG	Resize first, remove metadata, and run lossless optimization	Further lossless passes no longer reduce the file
Large full-color PNG	PNG with palette quantization, or JPEG if transparency is unnecessary	Quantize colors in controlled steps	Text edges, shadows, or brand colors visibly change
Artwork requiring transparency	PNG	Try lossless optimization before reducing the palette	Transparent edges develop halos or banding
WebP or AVIF candidate	Platform-dependent	Use only after confirming current crawler support	Any target platform produces a missing or incorrect preview

JPEG usually compresses continuous-tone photographs more efficiently. PNG is better suited to transparency, flat-color illustrations, interface captures, and graphics in which text must remain crisp.

WebP and AVIF can be excellent formats for ordinary page images, but browser support does not prove social-crawler support. When one og:image must serve several platforms, JPEG or PNG is the conservative default. Modern formats should be adopted only after platform documentation and live preview tests agree.

Lossless optimization versus lossy compression

These operations are not interchangeable:

Lossless PNG optimization rewrites the file more efficiently without removing image information.
Palette quantization reduces the number of colors in a PNG. It is lossy even when the visual difference is difficult to notice.
JPEG quality reduction discards image information to lower the file size.
Metadata stripping removes data such as comments or EXIF fields without changing the visible pixels.

Always keep the source asset so you can restart from the original instead of repeatedly recompressing an already degraded file.

A Repeatable Compression Workflow

1. Prepare the canvas and safe area

Export the image at the dimensions required by your priority platform. For a shared landscape asset, 1200 × 630 px is a reasonable starting canvas; for LinkedIn-first publishing, use 1200 × 627 px.

Keep the headline, logo, faces, and calls to action within a central safe area. Then inspect the design at a smaller size. Thin type, subtle shadows, and low-contrast details that look acceptable at full resolution can disappear in a compact feed card.

2. Select a format based on the pixels

Use JPEG when most of the canvas is photographic. Use PNG when transparency, sharp text, logos, or flat colors dominate. Do not preserve PNG simply because the source design tool exported PNG; a photo-only composition may be much smaller as JPEG.

3. Compress in controlled passes

For lossless PNG optimization, use OptiPNG:

optipng -o5 -out og-image-lossless.png og-image.png

OptiPNG recompresses the file without discarding image information. The exact reduction depends on how efficiently the input was already encoded.

If lossless optimization is insufficient, create a separate palette-quantized candidate with pngquant:

pngquant \
  --quality=65-85 \
  --output og-image-quantized.png \
  --force \
  -- og-image.png

pngquant is a lossy PNG compressor. Its quality range also acts as a guard: if the requested minimum cannot be reached, the tool exits rather than silently saving a lower-quality result. Its official documentation says reductions can often reach as much as 70%, but that is an example—not a guarantee for every asset.

For JPEG artwork, preserve the source and write optimized output to another directory:

mkdir -p optimized

jpegoptim \
  --max=82 \
  --strip-all \
  --all-progressive \
  --dest=optimized \
  og-image.jpg

Lower --max in small steps only if the image remains clear at preview size. Check text edges, gradients, skin tones, and high-contrast boundaries after each pass.

4. Automate resizing with Sharp

Sharp can make the export repeatable in a Node.js pipeline:

import sharp from 'sharp';

await sharp('og-photo-source.jpg')
  .resize(1200, 630, {
    fit: 'cover',
    position: 'centre'
  })
  .jpeg({
    quality: 82,
    progressive: true
  })
  .toFile('og-photo.jpg');

await sharp('og-graphic-source.png')
  .resize(1200, 630, {
    fit: 'cover',
    position: 'centre'
  })
  .png({
    compressionLevel: 9,
    palette: false
  })
  .toFile('og-graphic-lossless.png');

Sharp's cover mode may crop the input to fill the requested canvas, so inspect the composition rather than assuming the resize is harmless.

For an intentionally quantized PNG, set palette: true and test the result visually. Sharp documents that specifying PNG quality also enables palette-based quantization, so .png({ quality: 85 }) should not be described as a purely lossless setting.

5. Use a browser workflow when convenient

For an interactive workflow, LessMB can compress supported image files directly in the browser. Its product page states that processing happens locally without a server upload, which can be useful when you want to compare outputs without adding a command-line toolchain.

Regardless of the tool, verify the downloaded file's format, pixel dimensions, byte size, and appearance before publishing. A compressor cannot decide whether a particular logo or typeface remains acceptable for your design.

Record Results Instead of Guessing

Do not invent a universal compression ratio. Record the output from each candidate so the final choice is reproducible.

Candidate	Dimensions	File size	Compression method	Visual check	Platform check
Source export	Record value	Record value	Design-tool export	Baseline	Not published
Lossless candidate	Record value	Record value	OptiPNG or equivalent	Pass/fail	Pass/fail
Lossy candidate A	Record value	Record value	Record quality or palette settings	Pass/fail	Pass/fail
Lossy candidate B	Record value	Record value	Record quality or palette settings	Pass/fail	Pass/fail

Use the browser's network panel, an image-inspection tool, or simple command-line checks to collect the measurements:

file og-image.jpg
wc -c < og-image.jpg
curl -I https://example.com/images/og-image-v2.jpg

Record the final byte count rather than rounding it to a marketing-friendly percentage. If your team adopts a target such as 300 KB, document it as an internal performance budget—not as a universal crawler timeout threshold.

Add Complete Open Graph and X Card Metadata

Use absolute HTTPS URLs and include the four basic Open Graph properties. Add structured image properties so consumers know the media type, dimensions, and alternative description.

<meta property="og:title" content="How to Compress Images for Social Sharing" />
<meta property="og:type" content="article" />
<meta property="og:url" content="https://example.com/blog/compress-og-images" />
<meta property="og:description" content="A practical guide to smaller, clearer social preview images." />

<meta property="og:image" content="https://example.com/images/og-image-v2.jpg" />
<meta property="og:image:type" content="image/jpeg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="A social preview showing an image compression workflow" />

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="How to Compress Images for Social Sharing" />
<meta name="twitter:description" content="A practical guide to smaller, clearer social preview images." />
<meta name="twitter:image" content="https://example.com/images/og-image-v2.jpg" />
<meta name="twitter:image:alt" content="A social preview showing an image compression workflow" />

Width and height metadata provide useful dimensions in advance, but platforms may still fetch the file to validate and display it.

The Open Graph protocol allows multiple og:image values. When more than one is present, the first is preferred during a conflict. Put each image's structured properties immediately after its root og:image tag, and make sure the first image is the intended default rather than an old plugin-generated asset.

Publish the Image and Refresh Cached Previews

Upload the image to a stable, public HTTPS URL that does not require authentication, cookies, or a browser session. Follow your existing CDN caching policy instead of copying arbitrary Cache-Control values from another site.

When replacing an image, a versioned filename such as og-image-v2.jpg is generally clearer than overwriting the old asset. Update the metadata to reference the new absolute URL, deploy the page, and then request a fresh inspection where the platform provides that option.

A new filename does not eliminate the need to inspect the page itself. Platforms may cache both page metadata and media, and each service uses its own refresh schedule.

Verification Checklist

Complete this checklist against the deployed page:

Debugging Common Preview Failures

Symptom	Likely causes	What to do
No image appears	Private URL, blocked crawler, failed response, wrong MIME type, or unsupported format	Open the image without signing in, inspect HTTP headers, and test a conservative JPEG or PNG version
The wrong image appears	An earlier `og:image` takes priority or cached metadata is still active	Inspect the rendered HTML, move the preferred image first, use a versioned filename, and request a new inspection
Text is cropped	Critical content sits near an edge or the client uses a different display container	Move important elements inward and retest the actual desktop and mobile preview
Image looks blurry	Source dimensions are too small, text is too fine, or compression is too aggressive	Return to the source, export at the target dimensions, and increase quality or reduce quantization
Updated image does not appear	Page or media caching	Confirm the deployed metadata, use a new image filename, and allow for the platform's cache behavior
Large card becomes a thumbnail	Platform dimensions or card metadata are not satisfied	Compare the deployed asset with the platform's current official requirements and inspect the complete tag set

FAQ

What size should an Open Graph image be?

A landscape image around 1200 × 630 px is a practical cross-platform starting point. LinkedIn specifically documents 1200 × 627 px at 1.91:1. No single canvas guarantees identical presentation in every client, so keep essential content near the center and validate each priority platform.

Should I use WebP for `og:image`?

JPEG and PNG remain the conservative options for an image shared across several social crawlers. WebP may be appropriate when all target platforms currently document or demonstrate support, but browser compatibility alone is not sufficient evidence. Test a deployed page before adopting it.

What is the maximum file size for `og:image`?

Open Graph does not define a universal maximum. Platforms may impose their own limits; LinkedIn, for example, documents a 5 MB maximum for its sharing module. Use current official documentation for hard limits and a smaller, configurable internal budget for performance.

How do I make a PNG Open Graph image smaller?

Resize it to the required dimensions, remove unnecessary metadata, and try lossless optimization first. If the result remains too large, create a separate palette-quantized version with pngquant or an equivalent tool. Quantization is lossy, so inspect brand colors, gradients, transparency, and text edges.

Can I use one social sharing image on every platform?

Usually, but expect variations in layout, padding, and cropping. A landscape image near 1.91:1 reduces the number of assets you need, while a central safe area protects important content. Create platform-specific images when precise composition matters more than workflow simplicity.

Why is my `og:image` not showing?

Verify the absolute URL, HTTPS access, HTTP status, MIME type, crawler access, metadata order, and format. Then account for caching and run the page through the relevant platform inspector. A file that opens in your logged-in browser may still be inaccessible to a crawler.

Does compressing an Open Graph image improve page speed?

It reduces the data transferred when crawlers or preview clients request the image. It does not automatically improve page-rendering metrics if that image is only referenced in metadata. If the same asset also appears visibly on the page, its compression may affect both use cases.

Next Steps

Choose one high-priority page and record its current social image dimensions and byte size.
Export a fresh landscape source with important content inside a central safe area.
Produce separate lossless and lossy candidates, preserving every setting used.
Select the smallest candidate that passes the visual review.
Publish it under a versioned HTTPS filename and add complete metadata.
Validate the deployed page on Facebook, LinkedIn, X, and any messaging application important to your audience.
Turn the accepted dimensions, format choices, and byte budget into configurable build rules for future pages.