Implement a custom next/image loader for a self-hosted service
Tests next/image loader contract and URL construction. A strong answer defines a function taking src, width, and quality; returns a URL string for your service; and wires it via the loader prop or loaderFile config.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
Which approach correctly implements a custom next/image loader for a self-hosted service while keeping Next.js automatic sizing and quality behavior intact?
- a.A synchronous function that returns a URL string using src, width, and quality, wired globally via images.loaderFile.Correct
- b.Setting images.unoptimized to true in next.config.js and passing manually optimized URLs directly to standard img tags.
- c.An async function that fetches the optimized image bytes and returns the resulting buffer to the Image component.
- d.A React hook that accesses window.devicePixelRatio to manually calculate widths before constructing the image URL.
Why? this is the answer
The loader contract is a synchronous pure function that maps src, width, and quality to a URL string; Next.js then fetches the image itself. Option C mistakenly treats the loader as an async data fetcher, while option B bypasses the optimization system entirely rather than routing it to your service.
Just read this? Test yourself on what you have been reading.
Read the original → nextjs.org
- #next.js
- #react
- #image-optimization
- #performance
- #next/image
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on next.js — each one lists the topics its interview covers.
See open roles