Implement a custom next/image loader for a self-hosted service

WHAT THIS TESTS: This question tests whether you treat the next/image loader as a pure function that maps image request parameters to a URL string. Interviewers want to see that you understand the contract between the Image component and its loader, and that you know how to integrate a non-Vercel optimization backend without breaking Next.js automatic sizing, quality, or device-pixel-ratio behavior.

A GOOD ANSWER COVERS: First, the exact function signature. The loader receives an object with src as a string, width as a number, and quality as a number, and it must return a string URL. Second, URL construction. You should show how to build a request to your self-hosted service, for example by interpolating src, width, and quality into query parameters, and you should mention encoding src to handle special characters. Third, wiring. You can pass the loader function directly to the loader prop on a single Image component, or you can configure it globally in next.config.js by setting images.loader to custom and specifying a loaderFile path so every Image uses it automatically. Fourth, defaults. Quality falls back to 75 when not provided, and width is derived from the component props and the requesting device.

COMMON WRONG ANSWERS: A major red flag is treating the loader like a data-fetching or side-effect function instead of a synchronous URL builder. Another mistake is omitting quality from the constructed URL, which means your service cannot honor Next.js optimization hints. Some candidates suggest setting unoptimized to true, which avoids the question entirely and disables the performance benefits of the Image component. Finally, hardcoding widths or ignoring the src parameter shows a lack of understanding of the loader contract.

LIKELY FOLLOW-UPS: The interviewer might ask how you would protect your self-hosted endpoint from arbitrary image resizing abuse, so be ready to discuss URL signatures or allow-listed domains. They may also ask how device pixel ratio affects the width parameter, or how you would handle responsive images with the sizes prop alongside your custom loader. Another angle is asking how server components versus client components affect where the loader runs.

ONE CONCRETE EXAMPLE: Imagine your self-hosted service lives at https://images.example.com/optimize. Your loader function would look like this: const myLoader equals an arrow function taking src, width, and quality, then returning a template literal that builds https://images.example.com/optimize?url equals encodeURIComponent of src, then ampersand w equals width, then ampersand q equals quality or 75. In next.config.js you would set images.loader to custom and images.loaderFile to ./lib/my-loader.ts so the entire application uses it without passing the prop manually.