BlogImage Compression

How to Compress Photos for Online Sharing

Q: Should I use JPEG, WebP, or AVIF for a website?

For a site you control, WebP is a practical default—it is typically 25–34% smaller than a comparable JPEG at similar quality per Google's WebP documentation, and it is supported in all current major browsers. AVIF generally compresses further, though actual savings depend on the image and encoder; provide a JPEG or WebP fallback for older browsers. For social media and email, upload a high-quality JPEG and follow each platform's current official upload guidelines, because those services re-encode uploads and their format support varies.

Q: What quality setting should I start with?

Quality 80–85 (JPEG or WebP scale) is a common starting point for standard web photos. Treat it as an initial test value, not a universal standard—the right setting depends on the image, encoder, display size, and destination. After exporting, compare the result at 100% zoom and at normal viewing size, checking skies, shadows, fine textures, and edges for artifacts. Adjust and re-export from the original master until the result passes visual inspection.

Q: How do I know when a photo is over-compressed?

Zoom to 100% and look for block-shaped artifacts in smooth areas like sky gradients, banding in shadow tones, softened fine detail in hair or foliage, and color fringing on sharp edges. Then step back to normal viewing size—if artifacts disappear at the actual display size, the file may still be acceptable for that use case. If they remain visible, re-export from the master at a higher quality setting.

Q: Should I remove EXIF metadata before sharing photos online?

For most public web and social sharing, removing sensitive metadata—especially GPS location—is a reasonable privacy practice. Separately, camera model, lens, and shutter data add bytes but are less sensitive. IPTC copyright and creator fields are worth keeping for attribution. For client delivery or stock submission, check the recipient's or agency's current metadata requirements before stripping anything.

Q: Can image compression improve page performance?

Properly sized and compressed images can reduce image transfer size and improve loading speed, which may benefit Largest Contentful Paint (LCP). Core Web Vitals, including LCP, are part of Google's page experience signals, though good scores alone do not guarantee higher rankings. The measurable gain from compression depends on the original file size, the hosting setup, and how the images are loaded and prioritized on the page.

Learn how to resize and compress photos for websites, email, and social media—choose JPEG, WebP, or AVIF, set quality, convert to sRGB, and check results before sharing.

July 23, 2026

Updated: July 23, 2026

To compress photos for online sharing, start from the edited master file, make a copy sized to the destination's actual display dimensions, choose JPEG for broad compatibility or WebP/AVIF for a site you control, and lower the quality until artifacts become visible—then step back slightly. Use sRGB as the safest default for ordinary web and social sharing, remove sensitive GPS metadata, and compare the result at both 100% zoom and normal viewing size. Treat quality numbers and file-size figures as starting points: the best result depends on the image, encoder, display size, and destination platform.

Key Takeaways

Start with the destination: a self-hosted website, Instagram, email, or client delivery each has different format, size, and metadata requirements.
Resize before compressing: reduce the long edge to match the largest display width you actually need—sending extra pixels wastes bandwidth with no visible benefit.
Quality 80–85 is a practical starting point: visually test every export; the right value depends on the image and encoder.
sRGB is the safest default for ordinary web and social sharing; verify wide-gamut behavior on each specific platform.
Measure output file size and check visually: compare at 100% zoom and at normal viewing size before publishing.

Start With the Destination

The right settings depend on where the photo will be used. Use the table below as an initial decision guide, then verify current requirements on your target platform's official help pages—platform rules change.

Destination	Recommended format	Key considerations
Self-hosted website	WebP (AVIF + JPEG fallback via `<picture>`)	You control markup; serve responsive sizes with `srcset`
Instagram	JPEG; check current Meta official specs	Platform re-encodes uploads; consult the current Meta help page for supported sizes and ratios
Facebook	JPEG; check current Meta official specs	Recommended formats listed in Facebook's official photo guide; WebP/AVIF handling varies
Email	JPEG	Broadest mail-client support; keep files small for inline display
Client / stock delivery	JPEG or TIFF (lossless); follow recipient's brief	Keep full resolution and metadata as required; confirm stock agency specs

Resizing vs Compression: What Actually Reduces File Size?

These two steps are independent and both matter.

Resizing changes the pixel dimensions—a 6000 × 4000 px photo becomes 1600 × 1067 px. Downsampling discards pixels, but when the output dimensions match the actual display size, those discarded pixels were never going to be visible to the viewer. This is typically the largest single reduction in file size.

Compression changes how the remaining pixels are encoded into bytes. Lossless compression (PNG, lossless WebP) re-encodes the same pixel data more efficiently. Lossy compression (JPEG, lossy WebP, AVIF) discards data the eye is unlikely to notice; the degree of saving varies considerably by image content, encoder, and settings.

Confusing these two is the most common mistake. Always resize first, then compress from the resized copy—and always compress from the original master, never from an already-compressed file.

JPEG vs WebP vs AVIF: Which Format Should You Use?

Format	Typical use	Compression	Transparency	Notes
JPEG	Social platforms, email, maximum compatibility	Good	No	Universal historical support; survives platform re-encoding; stable choice for uploads you do not control
WebP	Self-hosted web, blogs, portfolios	Typically ~25–34% smaller than a comparable JPEG at similar quality (per Google's WebP documentation)	Yes	Supported in all current major browsers; practical default for self-hosted sites
AVIF	Self-hosted, maximum compression	Generally better than WebP and JPEG, though actual savings depend on image and encoder	Yes	Encodes more slowly; provide a JPEG or WebP fallback; browser and software support is still maturing
PNG	Screenshots, UI graphics with text, transparent overlays	Low efficiency for photos	Yes	Avoid for photographic content

SVG is a vector format—not applicable to photographs.

A practical rule for self-hosted sites: serve an AVIF source with a WebP or JPEG fallback using a <picture> element. For social media and email, upload a high-quality JPEG and follow each platform's current official upload specifications.

The Compression Workflow

Work through these steps in order. Each one removes bytes independently.

1. Keep the master untouched

Do all editing in your editor. Compression happens at export—keep the master at full quality. Never re-compress an already-compressed JPEG; each round compounds artifacts. Always export from the original master.

2. Resize to the display size

Before compressing, resize a copy to the largest width at which the image will realistically be displayed. Common starting points (verify against your actual CSS layout, device-pixel ratio, and srcset breakpoints):

Full-width hero / featured photo: ~1600–2048 px on the long edge
Standard article image: ~1200 px wide
Thumbnail / gallery preview: ~600–800 px

These are illustrative starting points. The correct dimensions for your site depend on your CSS display slots and the responsive breakpoints you serve.

3. Choose a quality setting—and test it

Quality settings are starting points, not universal standards. A quality value of 80–85 (JPEG or lossy WebP scale) is commonly used for standard web photos, but the right value depends on the image, the encoder, and the display context.

Use case	Starting quality (JPEG / lossy WebP)	What to watch for
Thumbnail, social preview	~70–75	Softness acceptable at small sizes; check for banding
Standard web photo	~80–85	Visually compare at 100% zoom and normal size
Portfolio hero, large display	~88–92	Larger file; inspect skies, shadows, and fine edges closely
Print or client delivery	95–100 or lossless	Not intended for web sharing

After exporting, open the file at 100% zoom and inspect skies, smooth gradients, shadow tones, fine textures (hair, foliage), sharp edges, and skin tones for artifacts. Then step back to the actual display size. If visible artifacts remain at normal viewing size, re-export at a higher quality from the master.

4. Use sRGB for ordinary web and social sharing

Convert the color profile to sRGB on export. sRGB is the safest compatibility default for standard web and social contexts—most browsers, CMS platforms, and mobile screens handle it reliably. If you upload a wide-gamut file (Adobe RGB, Display P3) to a platform that does not correctly apply the embedded profile, colors may appear flat or shifted.

If you work in a professional wide-gamut or HDR workflow, verify your target platform's current color management behavior rather than assuming sRGB is always required.

5. Handle metadata intentionally

Not all metadata is the same:

GPS location: remove before public sharing—it is a privacy risk.
Camera and lens data: generally harmless but adds bytes; remove for web if not needed.
IPTC copyright and creator fields: worth keeping for attribution.
Client or stock delivery: check the recipient's current requirements before stripping anything.

6. Export, measure, and verify

Export the file and check the actual output size. Treat these as example performance budgets, not hard rules—your correct targets depend on your layout, network environment, and real LCP measurement:

Image role	Example size budget	Why
Hero / LCP candidate	Under ~200 KB	Hero images are often the LCP element; reducing size can improve load time
Standard content image	Under ~100 KB	Content images accumulate; keeping each small helps overall
Thumbnail	Under ~50 KB	Small display size, small budget

If the file exceeds your target, drop quality by 5 and re-export from the master—do not re-save the compressed output. Verify LCP with PageSpeed Insights, which shows both lab data and, when available, real-world field data.

Serve Responsive Sizes With srcset and sizes

Serving a single large file works, but a responsive image setup sends smaller files to smaller screens:

<img
  src="photo-1200.jpg"
  srcset="photo-800.jpg 800w, photo-1200.jpg 1200w, photo-2048.jpg 2048w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width="1200"
  height="800"
  alt="Descriptive alt text"
>

Key rules:

Always set width and height attributes to prevent layout shift (CLS).
Do not use loading="lazy" on the LCP or above-the-fold hero image—it delays the most critical load. Use fetchpriority="high" on the LCP image if needed.
Use loading="lazy" on below-the-fold images only.
Test with PageSpeed Insights and check the LCP element.

See web.dev's guide to responsive images and LCP optimization for current best practices.

Recommended Export Settings (Lightroom Classic)

Lightroom Classic currently supports exporting to JPEG, JPEG XL, AVIF, PNG, TIFF, PSD, DNG, and Original. It does not list WebP as a direct export format in its current export dialog. If you need WebP output, export to JPEG or another supported format first, then convert using a dedicated tool.

Setting	Value
Format	JPEG (compatibility or social) or AVIF (self-hosted, with fallback)
Quality	80–85 as a starting point (test visually)
Color space	sRGB
Resize to fit	Long edge—match to your display slot (e.g., 2048 px for hero, 1200 px for article)
Resolution	72 PPI (the PPI tag does not affect on-screen sharpness; pixel dimensions do)
Output sharpening	Screen, Standard
Metadata	Copyright only (remove GPS and camera data for public sharing)
Limit file size	Available for JPEG only in current versions; use as a secondary check

Capture One and DxO PhotoLab offer comparable export dialogs—consult their current documentation for supported formats.

How to Check Whether Compression Has Gone Too Far

Visual verification catches problems that file-size targets miss. After exporting, inspect:

Sky and smooth gradients: look for banding or block artifacts in blue sky or fog
Shadow tones: check for color noise or posterization in dark areas
Fine textures: zoom to 100% and check hair, foliage, and fabric for smearing
Sharp edges: look for ringing or color fringing on high-contrast edges
Skin tones: watch for blotchiness or unnatural smoothing in portrait subjects

If artifacts are visible at 100% zoom and at the actual display size, the quality setting is too low—re-export from the master at a higher value. If artifacts disappear at normal viewing size, the compression may be acceptable for that context.

Tools for the Job

From your editor: Lightroom Classic, Capture One, and DxO PhotoLab all provide export dialogs with quality, resize, color space, and metadata controls. Check each application's current documentation for supported output formats.

Browser-based (one-off files): Squoosh processes images locally in your browser without uploading to a server—useful for testing format and quality comparisons on single files. For a browser-based workflow that lets you resize a photo, select an output format (JPEG, PNG, WebP, AVIF), adjust quality, and preview the result while keeping the file on your device, LessMB is a straightforward option.

Batch / command-line: ImageMagick and libvips can process folders of files. Consult the ImageMagick CLI documentation for current syntax and flag behavior—in particular, note that -strip removes embedded color profiles along with other metadata, which may affect color rendering. Test output visually before processing in bulk.

Common Mistakes to Avoid

Re-compressing an already-compressed JPEG. Each save compounds artifacts. Always export from the master.
Sending full-resolution files when only a fraction of the pixels are displayed. Downsampling to the display size avoids sending pixel detail that no viewer will ever see.
Uploading a wide-gamut file to a platform that does not handle it correctly. sRGB is the safest default for most web and social contexts.
Using a quality above 90 without visual justification. File size grows quickly for diminishing returns; test whether a lower setting is visually indistinguishable at the actual display size.
Omitting width and height attributes. Unsized images cause layout shift, hurting CLS scores.
Lazy-loading the LCP or hero image. This delays the most important element on the page. Only use loading="lazy" below the fold.
Stripping metadata you actually need. For client delivery or stock, confirm what the recipient requires before exporting.

Verification Checklist

Before publishing, confirm each image:

Practical Next Steps

Build one export preset per role (hero, article, thumbnail) in your editor using the table above as a starting point.
Run your last five published images back through the verification checklist—note which were oversized or under-inspected.
Set a format policy: WebP/AVIF with a JPEG fallback on your own site; JPEG for social platforms (always check each platform's current official specs).
Add a responsive image (srcset and sizes) to your most-visited page and measure the LCP change with PageSpeed Insights.
Standardize the handoff—whether a Lightroom preset, a batch script, or a browser tool like LessMB—so the resize-format-quality decisions are made once and applied consistently, not decided image by image.

Sources

FAQ

Should I use JPEG, WebP, or AVIF for a website?

For a site you control, WebP is a practical default—typically around 25–34% smaller than a comparable JPEG at similar visual quality according to Google's WebP documentation, and supported in all current major browsers. AVIF generally compresses further, though actual savings vary by image and encoder; provide a JPEG or WebP fallback via a <picture> element for older browsers. For social media and email, upload a high-quality JPEG and follow each platform's current official upload guidelines—those services re-encode uploads, and their format support varies by platform and may change.

What quality setting should I start with?

Quality 80–85 (JPEG or lossy WebP scale) is a common starting point for standard web photos. Treat it as an initial test value, not a universal rule—the right setting depends on the image, encoder, and display context. After exporting, compare at 100% zoom and at normal viewing size, checking skies, shadows, fine textures, and edges. If artifacts disappear at normal size, the setting may be acceptable. If they are visible at normal viewing size, re-export from the master at a higher value.

How do I know when a photo is over-compressed?

Zoom to 100% and look for block-shaped artifacts in smooth sky gradients, banding in shadow tones, smearing in fine textures (hair, foliage, fabric), and ringing or color fringing on sharp edges. Then step back to normal viewing size. If artifacts remain visible at the size the image will actually be displayed, the compression is too aggressive—re-export from the master at a higher quality setting.

What color space should I use for online photos?

sRGB is the safest default for ordinary web and social sharing. Wide-gamut files (Adobe RGB, Display P3) may look flat or color-shifted on platforms that do not correctly apply the embedded profile. If you work in a wide-gamut or HDR workflow, verify your specific target platform's current color management behavior before assuming sRGB is always required.

Should I remove EXIF metadata before sharing photos online?

For most public web and social sharing, removing GPS location data is a reasonable privacy step. Camera and lens metadata is less sensitive but adds bytes. IPTC copyright and creator fields are worth keeping for attribution. For client delivery or stock submission, always check the recipient's current requirements before stripping anything.

Can image compression improve page performance?

Properly sized and compressed images reduce transfer size and can improve loading speed, which may benefit Largest Contentful Paint (LCP). Core Web Vitals—including LCP—are part of Google's page experience signals, though good scores alone do not guarantee higher rankings. The practical gain depends on the original file size, your hosting and caching setup, and how images are loaded and prioritized on the page. Measure with PageSpeed Insights to see the actual LCP contribution.