Default Image Loader vs Custom Loader: Choosing Between Simplicity and URL Control in Next.js Production Builds

Direct answer

Use the built-in default loader for local images imported as modules, and configure remotePatterns for external images. Add a custom loader only when you must transform URLs for a CDN or asset prefix that the default loader cannot express, and verify the loader output under next build because next dev ignores loader configuration.

Why the dev/production gap happens

In development, the Next.js dev server serves image files directly from the filesystem and does not run the loader defined in next.config.js. A broken custom loader can therefore stay hidden during next dev. In production, after next build, the configured loader runs for every next/image instance. If no loader is configured, the default loader expects either an imported image module or a domain listed in remotePatterns. A custom loader that returns a raw src without the /_next/image asset prefix, width parameters, or CDN base path produces 404s in production even though the page worked locally.

Recommended steps

1. For images inside the project, import them and pass the module to src. The default loader handles hashing, sizing, and the /_next/image route automatically.
2. For images on external domains, add the domain to images.remotePatterns in next.config.js instead of writing a passthrough loader.
3. If you need a CDN prefix or custom path transformation, implement a custom loader that returns a full /_next/image?url=... or absolute CDN URL matching your deployment, then preserve query parameters such as w and q.
4. Verify with next build followed by next start, not next dev. Open browser dev tools, filter for image requests, and confirm each src contains the expected prefix and returns 200.

Minimal configuration example

// next.config.js
module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'example.com',
        pathname: '/uploads/**',
      },
    ],
  },
};

Assumptions and uncertainty

This guidance assumes Next.js 13 or later with standard next/image behavior and a production deployment using next start or static export. Loader behavior can change between major Next.js versions, so re-validate after an upgrade. Your specific Next.js version, image source locations, and CDN setup have not been verified.

Missing diagnostic detail

Are your production images local files imported in JavaScript, or remote URLs served from an external domain or CDN? This determines whether remotePatterns is sufficient or whether a custom loader is required.

Verification

• Run next build && next start.
• Inspect the Network tab for image requests; URLs should include /_next/image or your configured CDN path.
• Compare production src attributes against dev output to catch loader-related mismatches.