next/image vs img Tag: When to Use Which in Next.js

Next.js ships two ways to display images: the <Image> component from next/image and the plain HTML <img> tag. Choosing the wrong one costs you either performance or flexibility. Here's when to use each.

What next/image does

The <Image> component is a wrapper around <img> that adds:

• Automatic WebP/AVIF conversion: Converts JPEGs and PNGs to WebP or AVIF based on browser support.
• Automatic srcset generation: Creates multiple size variants using thedeviceSizes and imageSizes config.
• Lazy loading: Below-fold images load only when they enter the viewport (using native loading="lazy").
• Layout shift prevention: Reserves space via width and height props, preventing CLS.
• Blur placeholder: Shows a low-quality placeholder while the full image loads.
• Priority loading: priority prop adds <link rel='preload'> for LCP images.

The trade-offs of next/image

The automation comes with constraints:

• Server-side processing: Images are converted on the server at request time (or cached after first request). This adds cold-start latency and server CPU cost.
• Required dimensions: You must provide width and height props (or use fill mode). This can be awkward for user-uploaded content with unknown dimensions.
• Remote domains must be allowlisted: External image domains require configuration in next.config.js.
• Overhead for static images: Pre-converted WebP images go through the optimization pipeline even when they don't need to be.

When to use next/image

• Dynamic images from a CMS or database (unknown dimensions, various formats)
• User-uploaded images where you can't pre-process
• When you want automatic srcset without manual file generation
• When you need blur placeholders or priority loading with minimal code

When to use a plain img tag

• Pre-optimized images: Images already converted to WebP or AVIF at build time don't benefit from next/image processing.
• Known, fixed dimensions: Static assets where you control the source and have already sized them correctly.
• Avoiding server-side costs: High-traffic pages where the conversion overhead matters and you can pre-process images instead.
• Full HTML control: Complex <picture> elements with multiple sources, art direction, or custom loading behavior.

Performance comparison

The hybrid approach

Many production Next.js apps use both. Use <Image> for dynamic content (blog post images, product photos from a CMS) and plain <img> for static assets (hero images, icons, illustrations) that you've pre-optimized.

For pre-converting static images to WebP, use Picovert's converter or integrate Sharp into your build pipeline. See our full comparison in the next/image vs pre-convert article.

Common mistakes

• Missing sizes prop: Without sizes, Next.js defaults to100vw and loads unnecessarily large images on desktop. Always set sizes to match the actual rendered size.
• Not setting priority on LCP images: The above-fold hero image should have priority set to avoid lazy-loading the most important image on the page.
• Using fill mode without a positioned parent: fill requires the parent to have position: relative and explicit dimensions.