What Is an Image CDN?
An image CDN is a content delivery network that transforms images on the way through. It resizes, crops, compresses, and converts format at request time, then caches the result at edge locations near your visitors. If you are evaluating one, how to choose an image CDN covers the pricing models and what to compare.
What makes it different from a regular CDN
A regular CDN is distribution. Whatever file you give it is the file every visitor receives, just from a server closer to them. Upload a 4 MB photo straight off a camera and every visitor downloads 4 MB.
An image CDN changes the file. The same stored original becomes a 400px crop, an 800px crop, and a 1600px crop, in AVIF or WebP or JPEG, each generated on request. You store one thing and serve many.
Both the size and the format come from the URL. The browser picks between the sizes you offer through the srcset markup you write. Several services also sell automatic format selection as an opt-in parameter, Imgix’s auto=format and Cloudinary’s f_auto among them, which choose the format from the request headers instead of making you specify it.
How the transformation works
Transforms are described in the URL:
https://images.yoursite.com/photos/hero.jpg?w=800&h=600&fit=cover&fm=avifThat asks for an 800 by 600 crop encoded as AVIF. The service fetches the original from your origin, applies the operations, returns the result, and caches it. Change w=800 to w=400 and you get a new variant, generated on its first request and cached from then on.
Nothing is generated ahead of time. There is no build step producing six sizes of every image, and no re-encoding pass over your library when a new format becomes viable.
Resize, convert, compress, crop
Resizing does the most work. Most sites serve images far larger than the space they occupy, and a 3000 pixel photo in a 600 pixel column wastes the overwhelming majority of the bytes downloaded.
Format conversion is next. AVIF produces much smaller files than JPEG at similar perceived quality, and WebP somewhat smaller. Encoding at request time means you keep one original rather than a copy of every image in every format, and you can add a format later without touching your library.
Compression trades file size against fidelity through a quality parameter. Photographic content at quality 75 to 80 is hard to tell from the same image at 95 in normal viewing, while weighing well under half as much.
Cropping decides what happens when the requested aspect ratio does not match the original: fill and crop, or letterbox. Setting a focal point keeps an off-centre subject in frame when a wide image gets cropped to a narrow one.
Pull-based and push-based
Two architectures, and the difference decides how much adopting one costs you.
Pull-based services read from storage you already own. Point the service at an S3 bucket, an R2 bucket, or any public HTTP endpoint, and it fetches originals on demand. Nothing moves, and there is no second copy.
Push-based services require uploading images into their storage first. That gives you a media library with search and tagging, at the cost of a migration and vendor-billed storage.
Neither is universally correct. If you want a digital asset manager, push-based does more. If you already have storage and want transforms in front of it, pull-based is less work.
When it is not worth it
If your site has a dozen images that never change, a build step is simpler and free. Static site generators handle image optimization at build time perfectly well. If every image is a user avatar at one fixed size, generate that variant on upload and stop there.
The economics change when editors upload images at unpredictable dimensions, when you need proper responsive srcset markup, or when image processing currently competes with page rendering on your own web server. That is the case a pull-based service is built for: point Small Pics at the bucket you already have, and the sizes and formats come out of the URL with nothing to migrate.
A regular CDN solves none of that, and the difference between the two is worth being clear on before you pick one: image CDN vs regular CDN. If you already know you want one, how an image CDN works behind the scenes covers what actually happens on each request.
Frequently asked questions
- What is the difference between a CDN and an image CDN?
- A CDN caches and distributes files unchanged. An image CDN also processes them, resizing, cropping, compressing, and converting format based on what each request asks for. Most image CDNs include CDN delivery, so you get both.
- Does an image CDN replace my image storage?
- Not usually. Pull-based image CDNs, Small Pics among them, read from storage you already own, such as S3 or R2. Push-based services generally expect you to upload into their storage first, which means a migration and a second copy of your library.
- How does an image CDN know which format to serve?
- Usually you tell it in the URL. Several services also offer automatic format selection as an opt-in parameter, such as Imgix's auto=format or Cloudinary's f_auto, which read the request headers and choose for you. Without that, the common pattern is a picture element with multiple sources so the browser picks.
- Are transformed images regenerated on every request?
- No. The first request for a given variant generates and caches it at the edge. Subsequent requests for that same variant are served from cache without touching your origin.
- Does an image CDN help page speed?
- Images are commonly the largest element on a page, so serving a correctly sized modern format from a nearby edge tends to move Largest Contentful Paint more than most other optimizations.