Best Image Sizes for Blogs and Websites

Practical starting sizes for hero images, featured images, thumbnails, Open Graph previews, and product photos. Adapt each one to your layout, display density, and publishing platform.

Daniel Osei|April 2, 2026|11 min read

What size should an image be before you publish it on a blog or website?

Not the file size. The pixel dimensions. The width and height of the actual image before you even think about compression.

There is no universal size for every layout. A full-width hero, an inline article image, a thumbnail, and a product zoom image have different display requirements. The table below gives practical starting points, then the rest of the guide explains how to adjust them.

Quick Image Size Reference

These are performance budgets and starting dimensions, not upload requirements. Adjust them for your layout, source image, codec, display density, content platform, and visual-quality needs.

Why Dimensions Matter as Much as Compression

When you put an image on a web page, two things happen. First, the browser downloads the file. Then it renders it at whatever size your CSS says it should be. These two sizes are often wildly different.

A common situation is uploading a 4500x3000 JPEG while the blog layout displays it at 800 pixels wide. At the same aspect ratio, the displayed image is about 800x533, or 0.43 megapixels. Without a smaller responsive source, the browser still downloads and decodes the larger file before resampling it for display.

Pixel count scales with width multiplied by height. At the same aspect ratio, that 4500-pixel-wide image contains about 32 times as many pixels as an 800-pixel-wide version. Encoded file size does not follow the ratio exactly, but resizing can remove far more data than changing the quality setting alone.

The practical rule is to create responsive sources around the image's rendered size. An 800-pixel content column might use an 800-pixel candidate for standard displays and a larger candidate for high-density displays. A full-width hero needs different candidates for mobile and desktop rather than one oversized source for everyone.

Hero Images

A hero image is often the largest visible element near the top of a page and may become the Largest Contentful Paint candidate. Measure the actual page instead of assuming which element determines LCP.

Dimensions: There is no universal hero size or aspect ratio. For a full-width desktop layout, a source between 1600 and 1920 pixels wide is a common starting point. Choose the height from the design's aspect ratio and focal crop, then generate smaller responsive candidates for narrow screens.

Large or high-density displays may benefit from a wider candidate, while phones should not download it unnecessarily. Use srcset and sizes, then check analytics and the rendered result before adding a larger source.

File size: A starting budget of 150 to 300KB is reasonable for many photographic heroes, but complex images may need more and simple graphics may need much less. File size alone does not determine LCP. Server response, discovery priority, responsive selection, decoding, rendering, device speed, and network conditions also matter.

Format: Compare WebP and AVIF for photographs, and keep JPEG or PNG when a publishing system requires it. Savings vary by image and encoder settings. The JPG to WebP converter and PNG to WebP converter handle WebP conversion in the browser with nothing uploaded.

Do not lazy-load a hero that is visible in the initial viewport. Let the browser discover it in the initial HTML and give it appropriate priority. Images below the viewport can still use lazy loading.

Blog Post Featured Images

Featured images, also called cover images, appear at the top of blog posts and in blog index grids. They also double as the image that shows up when the post is shared on social media, which makes the aspect ratio choice important.

Dimensions: 1200x630 pixels is a common starting point for a featured image that also serves as an Open Graph preview. Social platforms can display or crop previews differently, so keep important text and faces away from the edges and test the platforms that matter to your audience.

If the on-page layout uses a different ratio, prepare a separate display image or define a deliberate crop. A 1200x630 candidate can still be used in the Open Graph metadata when it matches the current requirements of your sharing platforms.

File size: Start around 100 to 200KB and adjust after inspecting the result. A simple illustration can use less, while a detailed photograph may need more to avoid visible artifacts.

Format: WebP or AVIF can reduce transfer size for many photographs, but JPEG may still be appropriate for a workflow that requires it. Quality numbers are not equivalent across formats or encoders, so compare the visual result instead of copying one setting everywhere.

Inline Blog Content Images

These are the photos and illustrations within the body of an article. Diagrams, screenshots, product photos used as examples, charts. They sit inside your content column.

Dimensions: Match the rendered column width with responsive candidates. If an image displays at 750 pixels wide, a 750-pixel source can serve standard displays and a 1500-pixel source can serve a device that benefits from a 2x candidate.

Inline images that are not full-width, side floats, callout boxes, or images that share horizontal space with text should be sized to their actual display width, which is often 300-500 pixels.

File size: A budget around 50 to 150KB is a useful starting range for inline images. Screenshots with small text or detailed diagrams may require a larger file to remain readable.

Format: WebP or AVIF often suits photographs. SVG is useful for vector diagrams and icons. PNG or lossless WebP can preserve sharp screenshot text, with the best choice depending on transparency and tool support.

Retina Displays and the 2x Question

Many phones and laptops have high-density displays. At a device pixel ratio of 2, one CSS pixel maps to two device pixels on each axis, or four device pixels in area. An image displayed at 400 CSS pixels wide may therefore benefit from an 800-pixel-wide source.

Do not make every visitor download a 2x source. Provide multiple width candidates and let the browser choose according to the rendered slot and device pixel ratio. This is especially useful when text or fine detail must remain sharp.

But do not do this for everything. A 2x image is four times as many pixels, which means significantly larger file sizes even with compression. The practical approach is to use the srcset attribute in HTML to serve different sizes to different screens. For a blog featured image displayed at 800 pixels wide, you provide an 800px version for standard screens and a 1600px version for Retina:

<img
  src="cover-800.webp"
  srcset="cover-800.webp 800w, cover-1600.webp 1600w"
  sizes="(max-width: 800px) 100vw, 800px"
  alt="..."
/>

This lets the browser pick a suitable source based on the viewport, declared slot size, and device pixel ratio. Verify the sizes value against the real CSS layout so the browser does not select an unnecessarily large candidate.

If your publishing system cannot generate responsive variants, a source around 1.5x the largest rendered width can be a practical compromise. Test it on the devices your audience uses because one multiplier is not ideal for every image or layout.

Thumbnail Images

Thumbnails appear in blog index pages, related post grids, search result pages, and sidebar widgets. They are small, they are numerous, and they add up.

Dimensions: Match the thumbnail slot and crop ratio used by the card. Common slots range from about 300 to 600 pixels wide. Provide responsive candidates when the same card changes size across breakpoints.

File size: A starting budget of 20 to 60KB works for many small thumbnails, but detail and codec choice matter. Multiply the selected thumbnail size by the number loaded on the page to understand the total transfer cost.

Format: WebP or AVIF can work well for photographic thumbnails. The cumulative saving matters because an index page may load many cards.

Open Graph Images

Open Graph images are the pictures that appear when someone shares a link to your page on social media. They are not displayed on your actual web page. They are embedded in meta tags and retrieved by the social platform when generating a link preview.

Dimensions: 1200x630 pixels at roughly 1.91:1 is a common Open Graph starting point. Preview layouts and crops vary by platform and can change, so verify the current documentation for the services that matter to you.

If the featured image is already 1200x630 and survives the expected preview crops, the same asset can serve both roles. A separate social image is useful when the on-page crop or text placement does not translate well.

Keep faces, logos, and important text inside a central safe area. Link previews may use different rectangular crops or overlay interface elements, so content near an edge can be obscured.

File size: A budget around 100 to 300KB is a practical starting point, not a platform limit. Social crawlers retrieve this asset separately from the visible page, and each platform sets its own fetch and format rules.

Background Images

Background images span the full page width and often the full viewport height. They are decorative in most cases, which changes the quality calculation. A photo used purely as a textured background behind text can be compressed more aggressively than a feature photo where sharpness is the point.

Dimensions: Size the source for the largest rendered background slot and the crop created by background-size: cover. Provide smaller mobile assets and a larger candidate only when audience data and visual testing justify it.

File size: Start around 150 to 300KB for a large photographic background and reduce it further when the image remains suitable behind the foreground content. Decorative backgrounds can often tolerate more compression than product or editorial photography.

Heavy backgrounds can slow landing pages and portfolio sites. A full-screen photograph that looks impressive in a design mockup can add substantial transfer and decoding work when its dimensions and format are not optimized.

Product Images for E-Commerce

Product photos need separate treatment because their requirements differ from content images. A product view may support zoom, and shoppers may need to inspect fine detail.

Dimensions: Product-image requirements are platform-specific. A square source between 800 and 1600 pixels is a useful starting range when the marketplace accepts it and the product view supports zoom. Generate smaller thumbnail candidates separately instead of serving the zoom image in every card.

File size: Start around 100 to 300KB and inspect fine texture, labels, and edge detail at the actual zoom level. Marketplace limits and image-quality requirements take priority over a generic budget.

How to Adjust the Starting Budgets

The quick-reference table provides starting budgets, not pass or fail thresholds. A dense forest, textured fabric, or noisy low-light photo needs more data than a simple illustration with large flat areas.

Inspect the result at its actual rendered size. Raise the budget when important detail breaks down, and lower it when the image still looks clean. Then test the complete page because request priority, caching, layout, and script work also affect performance.

Before You Upload: The Right Order of Operations

Uploading the original file and relying entirely on a CMS can create unnecessary storage and processing. WordPress can generate several sizes from a supported high-resolution JPEG, while retaining the uploaded original unless site configuration or a plugin changes that behavior. Confirm which variant the theme actually renders.

When the publishing system does not create suitable responsive derivatives, resize to the needed dimensions first, then compress and upload.

The image resize tool lets you set exact pixel dimensions. For common dimensions, the 1920x1080, 1280x720, 1080x1080, and 800x600 tools resize and prepare images for download in the browser.

After resizing, compression brings the file size toward the budgets above. The compression tools at ImgTweak run entirely in the browser with nothing uploaded to a server. The image compression and Core Web Vitals guide explains how image delivery can affect page performance and search experience.

When an image still exceeds a published file-size limit, the compress to 100KB, 150KB, and 200KB tools aim for output at or below the selected upper limit.

A Useful Starting Point

For many article layouts, 1200 pixels wide is a useful source candidate. It can cover a typical content column and may also serve as a higher-density option for narrower slots. It is not a guarantee for every screen, and image size alone cannot guarantee a Core Web Vitals result.

A reliable workflow is to choose the rendered dimensions, generate responsive candidates, compare suitable formats, and compress while checking visual quality. Measure the published page to confirm that the browser selects the intended source.

Written by

Daniel Osei

Web Performance Engineer

Daniel has spent 6 years optimizing images and web assets for publishers and e-commerce brands. He writes about image formats, compression techniques, and web performance at ImgTweak.

View author profile and editorial background