Image CDNs let you keep a single high-resolution original and request any derivative by adding parameters to its URL — width, format, quality, crop. The server generates it once, caches it at the edge, and serves it thereafter.
Why It's Attractive
- One source of truth. No pre-generating a dozen sizes at build time, no regenerating everything when a design changes.
- Format negotiation for free. Most services will serve AVIF or WebP automatically based on the Accept header.
- Responsive images become trivial: a srcset is just the same URL with different width parameters.
- User-uploaded content works the same as your own assets — important when you can't control what people upload.
The Common Parameters
Names vary by provider, but the concepts are universal:
- Width / height — the target dimensions, usually with an option to preserve aspect ratio.
- Fit / resize mode — cover, contain, fill, inside. This decides whether the image is cropped or letterboxed when the ratio doesn't match.
- Format — auto (negotiated), webp, avif, jpeg, png.
- Quality — usually 1–100; "auto" modes pick per-image based on content complexity.
- Crop / gravity — which part to keep when cropping: centre, top, or smart/face-aware options.
- DPR — a device-pixel-ratio multiplier so you don't have to compute doubled widths.
The Cache-Key Explosion
Each unique parameter combination is a separate cached object. If your front-end generates arbitrary widths — say, exactly the container width in CSS pixels — you can create thousands of variants of the same image, each with its own cold-start transformation cost and cache entry.
The fix is discipline: pick a fixed ladder of widths (for example 320, 640, 960, 1280, 1920) and always round up to the nearest step. This keeps the cache hot and the bill predictable.
Cost Control
Most services bill on transformations, storage and bandwidth. Practical levers:
- Restrict the allowed parameter values, so a bug can't request 10,000 arbitrary sizes.
- Set a maximum output dimension.
- Cache aggressively and use long TTLs — a transformation should be paid for once.
- Don't transform tiny images; the overhead exceeds the saving.
The Security Setting People Forget
An open transformation endpoint that accepts arbitrary source URLs can be abused: strangers use your account to resize their images, or craft requests that hammer your origin. Two protections:
- Signed URLs — a signature that proves the parameter combination came from you.
- Allowlisted source domains so only your own origin can be fetched.
Enable at least one before going to production. Also consider that a public transformation URL reveals your original asset path, which matters if the original is higher-resolution than you intend to distribute.
When Not to Use One
For a small static site with a build step, generating a handful of sizes at build time is simpler, cheaper and has no runtime dependency. Image CDNs earn their keep with large catalogs, user-generated content, or frequent design changes.