What Size Should Blog Post Images Be? Widths and KB

There is no universal pixel width or KB limit that makes every blog fast. Photos, text-heavy diagrams, full-width covers and thumbnails need different treatment. Measure the rendered slot, preserve enough detail and test the actual delivered image rather than relying on the upload dimensions alone.

What size should blog post images be?

An image in a post is doing one of four jobs, each with its own target. Size all four the same way and the post ends up soft on a laptop and slow on a phone.

Use each image for the space it actually fills. A tall Pinterest design usually deserves its own composition rather than a forced crop of a landscape cover.

How wide should blog images be? Your column times two

A 1200px-wide file is a useful social-preview starting point, and Google Discover recommends at least that width for large images. That does not set the width of every figure inside a post. For example, a 600 CSS-pixel image at 2x density calls for 1200 source pixels, while a 720px image at 2x calls for 1440.

Published images are narrower than the advice assumes. The HTTP Archive's 2024 Media chapter measured the layout width of every image it crawled: the median img lands at 216 CSS px on desktop and 158px on mobile, and the widest image on a page reaches 680px at the desktop median. A 1200px file in a 216px slot carries about eight times the pixels a 2x screen can use.

Find your content column width in 30 seconds

1. Open a published post on desktop and on a narrow viewport.
2. Inspect the image element and read its rendered width in CSS pixels. Check the widest layout it is actually allowed to fill.
3. For a typical raster image, multiply that slot by two as a starting point. Preserve more source detail when zooming, high-density screens or fine text justify it.
4. After publishing, inspect the downloaded image and transfer size. A smaller upload helps only if the page delivers an appropriate candidate.

This blog’s image block declares a 720px desktop slot and responsive candidates, but a sizes value is only a description of the layout. It must match the actual CSS, including mobile gutters. Use the browser’s selected currentSrc and Network panel to check the result. A framework URL containing w=1920 is not, by itself, proof of the encoded file’s dimensions or transfer weight.

Why 2x is a useful starting point

At a fixed aspect ratio, doubling width quadruples the pixel count. A 3x export has 2.25 times the pixels of a 2x export, so the extra detail must justify its cost. A 390 CSS-pixel slot at 3x needs 1170 source pixels, which a 1440px image already covers. A larger slot on a 3x device may need more; test the actual layout instead of treating 2x as a hard ceiling.

How many KB should a blog post image be?

Around 150KB is a practical starting budget for a simple wide image, not a search-engine requirement or an appropriate cap for every diagram. Fine text and detailed screenshots may need more. Measure what the visitor downloads, and budget all images together.

For context, HTTP Archive’s 2025 Page Weight chapter reports median image transfers of 442KB on desktop inner pages and 354KB on mobile inner pages. Those samples cover many kinds of page, not just blogs. They are observations, not a recommended allowance or proof that a page at that weight is fast.

Eight figures at 150KB each total 1.2MB before the cover. Eight at 40KB total 320KB. Neither total establishes how quickly the post will load: viewport position, lazy loading, the LCP resource, network conditions and caching all matter. Check total image transfers and the files loaded at the start; the broken image checker helps locate large source files, while the browser Network panel shows the actual requests.

Use the page’s real measurements to judge the result. A good Largest Contentful Paint is 2.5 seconds or less for at least 75% of page visits. Reducing an image helps only when its bytes or delivery delay are part of that page’s bottleneck; a smaller file does not guarantee a Core Web Vitals pass.

Chrome’s Improve image delivery insight compares downloads with efficient bytes-per-pixel estimates and does not flag savings below 4KiB. A quiet report does not mean every file fits your quality and page-weight goals; inspect important images directly.

JPEG, PNG, WebP or AVIF: which format and when

The source files for this comparison are the same 1440 × 810 photograph, exported four ways: JPEG at quality 90, 99,966 bytes; JPEG at quality 80, 42,298 bytes; WebP at quality 80, 17,766 bytes; and AVIF at quality 55, 12,648 bytes. The diagram rounds binary kilobytes (KiB) to 98, 41, 17 and 12 respectively.

These numbers describe one soft-sky photograph, not a promise for every image. Fine foliage, small lettering and sharp UI edges can need much more data. Quality numbers from different encoders are not a controlled equal-quality scale: inspect the output and compare at a useful display size, not just at matching quality settings.

Broader measurements provide context, not a promise for this photograph. Google’s WebP benchmark reports lossy files 25–34% smaller than JPEG at equal SSIM quality. The HTTP Archive’s 2024 crawl found median densities of 3.8 bits per pixel for PNG, 2.0 for JPEG, 1.4 for AVIF and 1.3 for WebP. Those are different real-world image populations, not controlled exports of the same pictures.

• WebP is a useful default. It supports photos and transparency, with broad support in current major browsers. Test any older browsers your audience still uses.
• Compare AVIF for photographs. It was smallest in this particular sample, but that is not guaranteed for every image or encoder. Use a supported fallback when your audience or downstream platform needs one.
• PNG or lossless WebP for crisp text and UI. Inspect small labels and edges before choosing a lossy setting.
• SVG for suitable vector artwork. Diagrams, charts and logos can stay editable and sharp at multiple densities; a vector format does not itself make tiny labels readable.
• JPEG when compatibility calls for it. Social crawlers, publishing tools and browsers are different consumers. Google Search supports WebP, SVG and AVIF, but check the system that will actually read your file.

AVIF has one cost the compression tables never show: according to MDN, it has no progressive rendering, so the file has to arrive in full before any of it appears. MDN adds that the smaller file usually makes up for this, but that on large files the wait can become significant. Grigora's image to WebP converter turns a JPEG or PNG into WebP; for AVIF, use your editor's export dialog.

Featured image size, and why 1200 x 630 keeps coming up

The on-page featured image and the share card often reuse a file, but they do not have to. A wide page hero may need a larger responsive source; a social card can be a separate crop or design with its own URL.

1200 × 630 is a practical landscape social-card preset. Use it as a starting composition and check the platforms you publish to rather than assuming it can never be cropped. The Open Graph protocol defines the image URL and optional width, height and alternative text; it does not require that the social image be the same asset as the article hero.

Google Discover recommends something slightly different: at least 1200px wide, more than 300,000 pixels in total, a 16x9 shape, and max-image-preview:large switched on. It crops the image itself when it has to, so keep the subject away from the edges. In Google's case study of 11 August 2021, the food blog Kirbie's Cravings reported click-through from Discover up 79% after turning that setting on. Discover's guidance adds three rules: no generic image, not your logo, and nothing text-heavy.

Grigora’s Custom OG Image Maker builds a landscape card with a live preview. Its current download implementation renders a 1200 × 630 PNG. Check the downloaded file’s dimensions and compress it appropriately before uploading; do not assume every export needs to be halved.

A text-heavy card may work as a link preview while being a poor Discover image. Make a separate representative image when those jobs conflict. For portrait pins, Pinterest recommends 2:3, such as 1000 × 1500. A centered square crop of 1200 × 630 retains 630px of its width; forcing that same file into a 2:3 crop at 630px high retains only 420px. That is a crop calculation, not a rule that Pinterest will always apply. Recompose important text and subjects, then inspect the preview with the social image cropper.

The featured image finder shows which image a page offers for sharing. It reads og:image first, then twitter:image, then the first image in the page's structured data, then the first image on the page. If the cover came from somewhere else, read whether you can use any image on your website first.

Let the browser pick: srcset, sizes, width and height

The browser chooses a candidate using the supplied srcset, the slot described by sizes, device density and its own selection policy. Network and cached resources can affect the choice. MDN’s responsive-image guide explains resolution switching. Do not assume that every browser always downloads one exact rung.

Match sizes to the actual CSS. For a 720px maximum column with 16px gutters on each side of a narrow screen, an example is sizes="(max-width: 752px) calc(100vw - 32px), 720px". Use that only when it describes your layout; a different breakpoint or gutter needs a different value. Then check the selected URL and transfer size in the browser.

Then set width and height on every image, which only 32% of img elements on mobile do. web.dev is blunt about it: always include width and height size attributes, or reserve the space with CSS aspect-ratio. The browser takes the aspect ratio from those two numbers and holds the space open before the file lands, so text does not jump as images arrive. A good Cumulative Layout Shift score is 0.1 or less. The img attributes that do this are covered separately, and why a phone gets a different file from your laptop is the same mechanism at work.

Two mistakes that undo the rest

Lazy-loading the image at the top of the post. On 68% of mobile pages the LCP element contains an image, and 9.5% of those images carry loading="lazy". web.dev's instruction is one sentence: do not lazy-load images likely to be in the viewport when the page loads, especially LCP images. A lazy image cannot start downloading until the browser knows where it sits, so the file you needed first is the one you delayed.

Adding fetchpriority="high" does not cancel lazy loading. Remove lazy loading from an image needed immediately in the initial viewport, particularly the LCP image. Lazy-load appropriate offscreen images; a featured-image label alone does not determine its loading strategy.

Uploading whatever came out of the camera. A several-thousand-pixel photo may be much larger than its displayed slot needs. Resize or use a reliable image pipeline to generate suitable candidates, then inspect the delivered result. Rename the file while preparing it; how to name image files for SEO covers descriptive filenames and the limits of that signal.

Compression gets you part of the way. The captured result from the Image Size Compressor is 566KB, still well above the suggested 150KB starting budget. The tool preserves pixel dimensions: resize an unnecessarily large source before compressing it. Compare visible quality and actual downloaded bytes rather than treating a percentage saving as the finish line.

Does 72 DPI matter for blog images?

For normal responsive blog publishing, choose pixel dimensions and CSS size rather than chasing a 72-versus-300 DPI label. Changing density metadata without resampling adds no image detail. Resaving may still change metadata or compressed bytes, so unchanged file size is not a general promise.

CSS pixels and printer dots are different concepts. The HTML image-processing standard also defines specific conditions where EXIF resolution metadata affects intrinsic dimensions, so “DPI never affects a browser” is too absolute. Explicit layout dimensions and correct responsive sources are the practical controls for a blog image.

How Grigora handles blog image sizes for you

In Grigora’s classic editor upload pipeline, JPG, PNG and WebP photos are converted to AVIF, with up to six smaller widths from 1920px down to 300px when the source is large enough. The classic image block can provide srcset and sizes, allowing the browser to choose a candidate. The classic Post Featured Image block instead uses one image URL without those responsive candidates. Prepare that cover for its actual layout and compress it first; do not assume every phone receives a smaller version. These details describe the classic editor, not every image pipeline in Grigora.

Three checks stay with you. On classic template sites, lazy loading is enabled by default in the Post Featured Image block: turn it off when that image is needed in the initial viewport, particularly if it is the LCP element. Check the actual social preview and use a separate portrait Pin when needed. Finally, choose a relevant image; compression cannot fix the wrong subject. If you are starting a site, Grigora’s AI website builder can draft the layout from a description.

Blog post image size FAQs