You run your site through PageSpeed Insights and the first thing it flags is a hero image that's 3.6 MB. Your Largest Contentful Paint score is in the red, your mobile visitors are bouncing before the page even finishes painting, and Google is quietly docking your ranking for it. Meanwhile the image itself was just a normal photo — nobody intentionally made it slow.
Unlike email, a website doesn't have a hard size ceiling that clips your content — it just gets slower, page by page, image by image, until visitors leave. Every uncompressed JPEG on your site adds real, measurable seconds to load time, and search engines now factor that directly into how — and whether — your pages rank.
To compress JPEG for websites, resize the image to its actual display width, export at quality 70–80, and strip unnecessary metadata. This usually reduces a multi-megabyte photo to under 150–200 KB with no visible quality loss, while directly improving Largest Contentful Paint and overall Core Web Vitals scores.
What is JPEG compression for websites?
JPEG (Joint Photographic Experts Group) is a lossy image format — every time you save a JPEG at a quality setting below 100, the encoder permanently discards some pixel data using a compression algorithm called DCT (Discrete Cosine Transform). The lower the quality setting, the smaller the file and the more visible the degradation.
For websites specifically, compressing a JPEG well means combining three separate levers — used together, not in isolation:
- Resizing — scaling the image down to the largest size it will actually render at on the page. Serving a 4000px-wide photo into a 1200px content column is the single biggest source of wasted bytes on the modern web.
- Quality reduction — lowering the JPEG quality setting from a camera or design-tool default (often 90–100) to the web-optimized range of 70–80. At normal screen viewing distances, the visual difference is negligible.
- Metadata stripping — removing embedded EXIF data (GPS coordinates, camera model, shooting settings) and ICC color profiles that add KB of dead weight with zero rendering benefit in a browser.
Combined, these three steps routinely produce 70–90% file size reductions from a raw export — taking a 4 MB photo down to under 200 KB with no visible loss at normal display sizes.
Why image size matters for websites
Oversized images are consistently the largest single contributor to slow page loads on the web, and the consequences extend well beyond "the page feels slow."
- Core Web Vitals and rankings. Largest Contentful Paint (LCP) — one of Google's three Core Web Vitals — is very often the hero or above-the-fold image on a page. An oversized JPEG directly inflates LCP, and poor Core Web Vitals scores are a confirmed ranking signal.
- Mobile load time. A majority of web traffic is mobile, frequently on cellular connections with variable speed. A 3 MB image can add several seconds to perceived load time on a slow connection — long enough for many visitors to leave before the page finishes rendering.
- Bounce rate. Studies on page speed consistently show bounce rate climbing sharply as load time increases past the two-to-three-second mark. Heavy images are the most common reason pages cross that threshold.
- Bandwidth and CDN costs. Every visitor downloads your images on every page view (unless cached). A site getting 500,000 monthly pageviews with a 2 MB hero image is serving roughly 1 TB of image data a month that compression could cut to a fraction of that.
- Cumulative Layout Shift. Large, unsized images that load slowly can cause visible content jumps as they pop in, hurting another Core Web Vitals metric and creating a jarring user experience.
Step-by-step: how to compress JPEG for websites
- Determine the actual rendered width of the image. Open your browser's dev tools, inspect the image element, and check its rendered width in CSS pixels — not the file's native resolution. A hero banner that displays at 1200px wide should never be served as a 4000px file, no matter how high-resolution the original camera export is.
-
Resize the image first, before compressing. In Photoshop: Image → Image Size → set width to the rendered width (or 2× that for Retina/high-DPI screens), resample with Bicubic Sharper. In GIMP: Image → Scale Image. In command line:
magick input.jpg -resize 1200x output.jpg. Resizing alone, before touching quality, often cuts file size by 60–80%. -
Export or re-save at quality 70–80. In Photoshop: File → Export → Export As → JPEG, set Quality to 75. In GIMP: File → Export As → set quality to 75 in the JPEG options dialog. In command line:
magick input.jpg -quality 75 output.jpg. Quality 75 is the standard web sweet spot — small files with no visible degradation on screen. -
Strip EXIF and color profile metadata. Photoshop and most cameras embed metadata by default. In Photoshop's Export As dialog, uncheck "Metadata." For command line, ExifTool is the standard:
exiftool -all= output.jpg. The Rebrixe JPEG Compressor strips metadata automatically. This typically saves another 5–20 KB per image. -
Run a final optimization pass. After resizing and quality reduction, run the result through a dedicated encoder like MozJPEG or jpegoptim, which re-encodes using more efficient Huffman tables without touching the quality number:
jpegoptim --max=75 --strip-all output.jpg. This usually squeezes another 5–15% beyond what a standard export tool achieves alone. -
Add responsive attributes in your HTML. Use
srcsetandsizesso browsers request the right resolution per device, and addloading="lazy"to any image below the fold. A perfectly compressed image still wastes bandwidth if it's served at full size to every device regardless of screen width. - Re-test and confirm the final size. Re-run PageSpeed Insights or Lighthouse and check the resulting file size and LCP score. Target under 200 KB for most images, under 150 KB for LCP-candidate hero images. If you're still over target, the most common cause is forgetting step 1 — the image dimensions still exceed the rendered width.
Common mistakes that hurt page speed
1. Compressing without resizing first
The most common mistake on the web: lowering the JPEG quality slider on a 4000px-wide original and wondering why the file is still 700 KB. Quality reduction alone on an oversized image produces a large file at lower quality — the worst of both worlds. Always resize to the actual rendered width before touching the quality setting.
2. Skipping responsive images entirely
A single compressed JPEG served identically to a 4K monitor and a budget Android
phone is still wasteful. Without a srcset and sizes
attribute, mobile visitors download the same large file desktop visitors do.
Responsive images let the browser request a size appropriate to the actual device.
3. Loading every image eagerly
Images below the fold that load eagerly compete with above-the-fold content for
bandwidth and delay the metrics that matter most, like LCP. Add
loading="lazy" to any image not visible on initial page load, and
reserve eager loading for the single LCP candidate image only.
4. Re-compressing an already-compressed JPEG
Every time a JPEG is opened and re-saved at a quality setting below 100, a new layer of compression artifacts stacks on top of the existing ones. A photo saved once at quality 75 looks noticeably better than one saved at quality 90, then reopened and re-saved at quality 75. Always compress from the original high-quality source file.
Real-world compression examples
These results come from applying the full workflow — resize to rendered width, export at quality 75, strip metadata, MozJPEG pass — to common website image types:
The pattern holds across nearly every case: resizing to the correct render width does most of the work, and quality reduction finishes the job. Starting from an original high-resolution source consistently achieves 80%+ reduction with no perceptible quality loss on screen.
Tool comparison
The right tool depends on your workflow — browser-based for one-off images, build pipelines or CDN-level automation for sites publishing images at scale.
| Tool | Type | Resizing | Metadata strip | Privacy | Best for |
|---|---|---|---|---|---|
| Rebrixe JPEG Compressor | Browser | Yes | Auto | Client-side only | Quick one-off web image prep, no uploads |
| Squoosh | Browser | Yes | Manual | Client-side only | Visual before/after comparison with MozJPEG/AVIF |
| TinyJPG | Browser / API | No | Yes | Server upload | Batch compression via API for content teams |
| jpegoptim (CLI) | CLI | No | --strip-all | Local | Build pipelines and CI image optimization |
| Image CDN (Cloudinary, imgix) | CDN service | Yes, automatic | Yes | Cloud-hosted | Sites needing automatic responsive resizing at scale |
| ImageOptim (macOS) | Desktop app | No | Yes | Local | macOS drag-and-drop batch workflows |
Compress your website JPEG right now — free
The Rebrixe JPEG Compressor runs entirely in your browser. Your images are never uploaded to a server — resizing, compression, and metadata stripping all happen locally. No account, no file size limit, no watermarks. Set your target width to match the image's rendered size on your page, choose your quality level, and download the result in seconds.
Frequently asked questions
<picture> element gives the best balance of size and compatibility.
srcset. A compressed image still served at
3000px wide into a 400px mobile container wastes bandwidth regardless of its
quality setting. Pair compression with correct sizing, lazy-loading for
below-the-fold images, and responsive attributes for full results.