Does Next.js Cache Images? Fix a Stale `next/image`

Yes—Next.js can cache optimized images served through next/image. But a stale picture is not automatically an optimizer-cache problem. First find the URL the browser actually displays, then check whether the image at its original source URL has changed. Adjusting Next.js’s cache setting cannot make an unchanged source image current.

Find the request that displays the picture

Open your browser’s Network panel, reload the page, and select the image request. Look at its request URL and response headers. If the displayed request goes to your site’s /_next/image endpoint, investigate the optimized response. If it goes directly to the original image URL, investigate that response instead. A URL belonging to a custom image provider points you toward that provider’s caching rules.

Copy the displayed URL from the Network panel. Get the source URL from the url parameter in the optimized request, if present, or from your application’s image configuration. If the source is already old, fix the image at that URL or publish the changed image at a new URL before tuning optimization. If the source is current but the displayed response is old, compare their headers and content to narrow down which layer is serving the older result.

For example, substitute the source and displayed URLs you found. Use the complete /_next/image URL, including its query string:

SOURCE_URL='https://example.com/images/team.jpg'
DISPLAYED_URL='https://example.com/_next/image?url=https%3A%2F%2Fexample.com%2Fimages%2Fteam.jpg&w=1200&q=75'

curl -sS -D source-headers.txt -o source-image "$SOURCE_URL"
curl -sS -D displayed-headers.txt -o displayed-image "$DISPLAYED_URL"

Read Cache-Control and other relevant response headers in the two header files, and open the downloaded images to see which picture each response contains. The example URLs are placeholders; use your actual requests. Image bytes need not match even when the pictures do: the optimized response can have a different format. Next.js also caches configured output formats separately, so compare the format the browser requested when diagnosing a discrepancy.

What minimumCacheTTL changes

The Image documentation defines images.minimumCacheTTL as a TTL, in seconds, for cached optimized images. The Pages Router Image documentation describes the same setting. It applies to that optimized-image cache—not to every image response your browser might receive.

Set an explicit minimum in next.config.js when optimized images at stable URLs need a shorter configured lifetime:

module.exports = {
  images: {
    minimumCacheTTL: 120,
  },
}

Here, 120 is the minimum you chose, in seconds; it is not a purge command or a promise that an existing cached result changes immediately. In its discussion of Next.js 15, LogRocket describes the optimized image’s cache age as using the larger of the source image’s Cache-Control age and minimumCacheTTL. That is an important reason to inspect the source headers: lowering the minimum alone may not shorten the effective age when the source advertises a longer one. Check the headers returned by your deployed setup rather than assuming one setting explains the observed response.

When a new URL is the better fix

If image content changes while its URL stays the same, a cache can continue serving the older content under that URL. Giving changed content a new URL makes the change explicit. Static image imports are particularly useful for bundled assets: Next.js hashes their file contents, producing an asset URL that changes with the content, and serves them with an immutable cache header. That is a different strategy from shortening the TTL for an optimized image fetched from a stable source URL.

Choose based on who controls the image. For a bundled asset you update with your application, consider a static import. For an externally managed image that must keep the same URL, inspect its source cache header and configure the optimized-image TTL with that header in mind. If the external system can publish a distinct URL for each revision, using that URL avoids relying on a cache to notice changed bytes at an unchanged address.

Check who owns optimization

On a self-hosted deployment using next start, Next.js image optimization works without additional configuration. With a custom loader, optimization is delegated to its provider; check that provider’s caching and invalidation documentation rather than assuming minimumCacheTTL governs its responses. Browser, CDN, and hosting-layer caching can also affect what you see, so keep their response headers distinct from the source and /_next/image responses.

After changing the TTL or publishing a new image URL, reload with Network tools open. Confirm which URL the browser requests, inspect the response headers, and check the picture returned. That final request—not the configuration file alone—tells you whether the displayed image is now current.