What is a good file size for a blog cover image?

Aim for well under 150 KB for a 1200×630 cover. Export it as WebP at quality 80-86 from the right dimensions and you will usually land between 60 and 120 KB with no visible quality loss. If a cover is creeping past 300 KB, the problem is almost always the wrong dimensions or the wrong format rather than the quality dial.

Does compressing an image always reduce quality?

No. Quality only drops when you push the quality setting too low or stack two lossy passes on top of each other. At WebP quality 80-86 the compression discards detail your eye cannot see at normal viewing distance, so a properly compressed cover looks identical to the original while weighing a fraction as much.

Why is my blog cover image so large?

Usually the dimensions are the cause, well ahead of the compression. A 4000px export dropped into a 1200px slot carries roughly ten times the pixels it needs, and that bloat dwarfs anything the quality slider does. Resize to the size the slot actually renders first, then compress - that order fixes most oversized covers in one step.

Compress a Blog Cover Without Losing Quality

A 1200×630 cover should land well under 150 KB, and you lose no visible quality getting there. Export it as WebP at quality 80-86 from the right dimensions and you will usually see somewhere between 60 and 120 KB on disk. That is the whole answer; the rest is the order you do it in, and why most oversized covers are oversized for a reason that has nothing to do with the quality slider.

The reason “compress” feels risky is that people reach for it last, after the file is already wrong. They export a 4000px masterpiece, watch it weigh 2 MB, then yank the quality slider down to 40 to claw the size back and wonder why the cover looks soft. The size was never the quality’s fault. It was the dimensions and the format, and once those are right the quality dial barely has to move.

Do it in this order: dimensions, then format, then quality

Compression is the last of three steps, and the first two do most of the work. Get them out of order and you fight the quality slider for bytes it was never holding.

Right dimensions first. A cover only needs as many pixels as the largest slot it renders into, times two for retina. Ship a file sized to that and you have already deleted the biggest source of bloat. The exact target per slot is its own topic - what size a blog cover should be lays out 1200×630 for the share card and 1280×720 for the hero.
Right format second. WebP at the same visible quality runs 25-34% smaller than JPG and about 26% smaller than PNG, so the format choice alone shaves a third off before you touch a single setting. Which format wins for which image is the job of WebP vs JPG vs PNG; for a cover, the answer is almost always WebP.
Quality dial last. Only now, with the right size and the right format, do you set the quality. And by this point you are just nudging it.

Skip step one and no quality setting will save you. A 4000px file carries roughly ten times the pixels a 1200px slot can show, and that is 10x the data before compression even starts. Resize before you compress and most “huge cover” problems vanish in a single move.

Quality 80-86 is the sweet spot for a photo cover

For a photographic cover, set WebP quality between 80 and 86. That band is where the encoder throws away detail your eye cannot resolve at normal viewing distance while keeping everything it can. Below about 70 you start to see it: banding in a clear sky, blockiness around hard edges, a faint smear where the photo meets your title. Above 90 the file grows fast for detail nobody will ever notice on a screen.

A cover crop compressed too hard, the gradient banding and the letter edges breaking into blocks. — Push the quality too low and the gradient bands and the edges blockify; ease off, or use WebP, and it stays clean at a similar weight. Open the fix in Lede

The same crop at a sensible quality, the gradient smooth and the edges clean. — Push the quality too low and the gradient bands and the edges blockify; ease off, or use WebP, and it stays clean at a similar weight. Open the fix in Lede

With cwebp, that is one flag:

cwebp -q 84 -m 6 cover-source.png -o cover.webp

The -q 84 sets quality in the sweet spot and -m 6 tells the encoder to work its hardest for the smallest file at that quality. It is slower to encode and identical to look at. You run it once per cover, so the extra second costs you nothing.

If your cover is a flat graphic instead - solid color, a logo, sharp text on a plain background - quality behaves differently, and lossless WebP is often the better trade. That is the format question again, and WebP vs JPG vs PNG covers when to flip to lossless.

Export at 2x and the file still stays small

Exporting a cover at twice its display width sounds like the opposite of compressing, so people worry it blows the budget back open. It does not. A 2x WebP at quality 84 is still a small file, because 2x a correctly-sized cover is a deliberate, bounded number, far below the accidental 4000px export that started this whole problem. You are doubling a correct size, which keeps the file modest, so a retina-sharp file still lands well under your KB budget.

Why a slot-sized cover looks soft on high-DPI screens, and how devicePixelRatio turns one CSS pixel into two physical ones, is its own topic - exporting a retina-sharp cover walks through the mechanism and the exact 2x targets per slot. For file size, the only thing that matters here is that the 2x export stays cheap.

What “under 150 KB” looks like in practice

Numbers help here, so a rough map of where a 1200×630 cover lands by format and setting:

Export	Typical size	Verdict
PNG, full-color photo	1.5-3 MB	far too heavy; wrong format for a photo
JPG, quality 90	250-450 KB	fine, but heavier than it needs to be
WebP, quality 84	60-120 KB	the target; sharp and light
WebP, quality 50	30-50 KB	smaller, but you can see the damage

The WebP quality-84 row is the one to aim for. Well under 150 KB, no visible loss, and a file that loads before a reader notices it is loading. Most of the gap between that row and the heavy ones is format and dimensions, which is exactly why those two steps come first.

If a cover still refuses to drop under 150 KB after all three steps, it is almost never the quality. Check that you are not shipping a 4000px file, that you exported WebP and not PNG, and that you did not stack two lossy passes (more on that next). One of those three is the culprit nearly every time.

The one trap: compressing twice

The mistake that actually costs you visible quality is double compression - exporting a lossy JPG, then re-saving that JPG as lossy WebP. Each lossy pass discards detail, and the second pass discards detail from a file that was already missing some. The artifacts stack, and now your “compressed” cover looks worse than either format would alone.

Compress once, from the original. Every extra lossy pass spends quality you cannot get back.

The fix is to always export from your source - the editor, the camera file, the design tool - straight to your final WebP, in one pass. Never compress an already-compressed file. If you built the cover in a design tool, export the WebP from there directly rather than saving a JPG and converting it after.

A quick checklist

Resize to the right dimensions for the slot first - a cover does not need more than 2x its display width.
Export as WebP for any photographic cover, ahead of PNG or JPG.
Set WebP quality to 84 (anywhere in 80-86 is safe), with -m 6 for the smallest file at that quality.
Confirm a 1200×630 cover lands under 150 KB; if it does not, the problem is dimensions or format, not quality.
Compress in one pass from the source - never re-save an already-compressed file.

Get those right and the cover is the cheapest win on the whole page: same picture, a fraction of the bytes, and a load so fast it never registers. None of it needs a separate tool or a round trip through a converter.

When you want a cover that exports as an optimized 2x WebP in one click, already sized and compressed right, open Lede - it has presets for every size and a gallery of templates to start from. Build it, export it, and ship the lighter file.