Compress an image to 300 KB
300 KB is preset and reserved for the one image that has to look good; each file gets its own search for the highest JPG or WebP quality that fits under it.
Your images
Settings
Generated images
- Nothing uploaded
- Free, no sign-up
- Strips EXIF
- Batch files
The CMS style guide says every image under 300 KB. The hero photo for the post, straight from the camera, is 4.2 MB, and the media library either refuses it or accepts it and quietly makes the page slow. Or Lighthouse already told you: a mobile score in the 50s, with "Properly size images" pointing at pictures that looked fine over your own Wi-Fi.
300 KB is a reasonable ceiling for the one image that has to look good, and a bad default for every image on the page. Lighthouse scores mobile pages on a simulated 1.6 Mbps connection; at that speed 300 KB takes about 1.5 seconds to arrive, and five of them are 1.5 MB, roughly 7.7 seconds of image download before anything else loads. Spend the 300 KB on the hero and go lighter below it.
The target here is fixed at 307,200 bytes and the format row starts on JPG. The search for the quality that fits runs on your machine, per file, so the photo reaches no server before the media library does. Width is not a setting on this page, yet it is what decides how good 300 KB looks, so a camera-size hero should stop at Resize image on its way here.
How it works
The width belongs to the slot, so decide it before the file arrives; here you only check the format and read the cards.
Drop the post images in
Drag the whole set, click Choose images, or paste a screenshot with Ctrl+V on desktop. JPG, PNG, WebP, GIF, BMP, SVG and iPhone HEIC all load; HEIC pulls a decoder of about 1 MB the first time and is decoded on your device.
Check the format, skip the slider
The panel opens on JPG with 300 KB applied and the quality slider ignored, since the search chooses that number; switch the format row to WebP when the site is yours. No width input exists here, so a camera-size hero is best sized on Resize image first, at 1,600–2,000 px for a full-width slot or 1,200–1,600 px inside the post.
Generate, compare, download
Press Generate images and read each card against its slot: new size beside old, the percentage cut, the output width and height, and target met, or smallest possible when no quality got the file under 300 KB. Compare lays a slider over the original, useful for checking a hero's sky for banding, and the finished set downloads as one .zip for the media library or one file at a time.
Why 300 KB fits one hero and not the whole page
Lighthouse's mobile profile simulates a 1.6 Mbps line. On it, 300 KB of image is about 1.5 seconds of download, which leaves room inside the 2.5-second Largest Contentful Paint target when the hero is the only heavy thing above the fold. Each additional 300 KB image adds another 1.5 seconds of data.
| Images at 300 KB | Image weight | Download at 1.6 Mbps | What to do |
|---|---|---|---|
| 1 (hero only) | 300 KB | about 1.5 s | Compress here |
| 3 | 900 KB | about 4.6 s | Hero here, body photos at 200 KB |
| 5 | 1.5 MB | about 7.7 s | Body photos at 100–200 KB, lazy-loaded |
| 10 (gallery) | 3 MB | about 15 s | Thumbnails under 100 KB |
Width decides what 300 KB looks like
The budget is 307,200 bytes, about 2.46 million bits. Over a 12-megapixel camera frame that is 0.2 bits per pixel, which no JPEG encoder can make look like a photograph. Resized to 1,600 px wide, the same frame gets roughly 1.3 bits per pixel, enough for a quality setting in the 70s or 80s with no visible loss on screen.
A JPEG reaches 0.2 bits per pixel only at a quality around 10 to 25, so a full-size hero dropped straight in ends one of two ways: the search stops down there and hands back a 4,000 px file with blocking across the sky, or, on a busier scene, nothing fits even at quality 5 and the page shrinks the frame 15% a step at quality 72, landing on a width the algorithm picked rather than the theme. Width is not adjustable here, so set it on Resize image before the file arrives; the search then finishes on quality alone, at the width the slot renders. Both stages are laid out in full on the general Compress image page.
JPG, WebP or AVIF on a site you control
JPG is the preset because every CMS accepts it. On a site you control, switch the format row to WebP: every current browser displays it, and Google's measurements put it 25–34% smaller than JPG at equal visual quality. Under a fixed 300 KB cap that saving comes back as quality: the search stops higher, or the same quality fits at a larger width.
AVIF cuts further, but this site can only write it where the browser has an encoder: the AVIF button is added to the format row only after the browser proves it can produce the format, which today means Chrome, Edge and Opera, and usually not Safari or Firefox. PNG has no quality setting, so it goes straight to the downscale stage and loses pixels until it fits; keep PNG for flat graphics and screenshots.
What WordPress does to the file after upload
WordPress keeps the uploaded file on disk and re-encodes every copy it makes, thumbnail, medium and large included, at JPEG quality 82. When either side exceeds 2,560 px it also writes a -scaled copy at that quality and treats it as the full size: the attachment URL, galleries and lightboxes serve the scaled file, and the original is reachable only through its own link. A 4,000 px hero compressed to 300 KB here therefore reaches visitors as a 2,560 px re-encode at whatever size quality 82 produces, rarely 300 KB. Resize it below 2,560 px first, then compress, and the full size WordPress serves is the exact file you checked on the card.
The download also carries no EXIF: capture time, camera model and GPS coordinates are gone before a product shot taken at home lands on a public page.
Frequently asked questions
Is 300 KB too big for a blog post image?
For the hero or a full-width banner, no. For photos inside the post, sized to an 800–1200 px column, aim for 100–200 KB; five 300 KB in-body images add 1.5 MB to the page. The Compress to 200 KB page runs the same search with that target.
Lighthouse still flags "Properly size images" after the hero is under 300 KB. Why?
That audit compares each image's pixel dimensions with the space it renders in, not its byte size, and mobile Lighthouse renders a 412 px wide viewport at 1.75× density. A lone 1,600 px hero is oversize there however little it weighs; what clears the flag is a srcset with smaller candidates, which WordPress builds from the upload (768, 1024 and 1536 px copies) as long as the theme outputs them.
Why did the output come back smaller in pixels than the original?
Because no quality between 5 and 96 got the file under 307,200 bytes, so the page shrank it 15% per step until one did; a busy full-frame photo or any PNG takes that route. To land on a width you chose instead, size the image on Resize image first and run it here again, where the search then stops in the quality stage.
Does the 300 KB budget apply to the Open Graph share image too?
It fits, but it does not need to: an og:image is fetched once by Facebook, LinkedIn or Slack when the link is shared, and browsers never download it with the page, so it adds nothing to load time. At the 1200 × 630 px those platforms recommend, 300 KB works out to more than 3 bits per pixel, and the search usually stops at quality 90 or above.
Will the photo's GPS location end up on my site?
No. Every file this page writes has its EXIF stripped, including GPS, capture time and camera model, and each card shows an EXIF stripped tag. The stripping happens in your browser along with the compression; nothing is sent anywhere.
Can I fix an image that is already published, or only new uploads?
Download it from the media library first; for anything WordPress scaled, the attachment details list an Original image link, and that is the file to take. Run it through Resize image and this page, then upload the result. WordPress has no built-in replace, so point the block or featured image at the new file, or use a media replacement plugin to keep the old URL.
Can I run the hero and the in-post photos in one batch?
Yes, but every file in a run gets the same 307,200-byte target, and there is no per-file target on this page. Drop the hero and any full-width banners here, take the in-post photos to the 200 KB page in a second run, and download each batch as its own .zip.