What an image CDN does
A CDN keeps copies of your files on servers close to your visitors and sends them from there. For most files that is the whole job: the bytes that leave the edge are the bytes your origin served. An image CDN adds one step. Between its cache and the visitor it can change the image itself, for four reasons.
Format. On photographs, WebP and AVIF are usually much smaller than the JPEG you uploaded: in our measurement a 262,025-byte news photo came out as 113,860 bytes of WebP and 86,936 bytes of AVIF. The image CDN converts each image into a format the visitor's browser accepts, so a browser that handles AVIF gets AVIF and an older one still gets an image it can show.
Size. A phone that displays a photo 400 pixels wide does not need the 2,400-pixel upload. With a width or a height in the URL, the image CDN scales the image down to what the page actually shows.
Compression. Even without a format change, re-encoding at a sensible quality and dropping data the screen never uses takes bytes off most uploads: the same news photo, re-encoded as JPEG, went from 262,025 to 186,137 bytes.
Cache. Every result is stored at the edge. The conversion runs once per variant, and every later visitor gets the stored copy at normal CDN speed.
Your originals stay where they are: you upload one good-quality file, and every variant is produced from it in the delivery path. Nothing has to be exported again when a new format arrives or a layout changes size.
One URL, several formats: Accept and Vary
Every image request a browser makes carries an Accept header listing the formats it can display. Chrome sends image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8; a browser without AVIF support leaves image/avif out. The image CDN reads that list on each request and answers the same URL with AVIF, WebP or the original format. The file name does not change, so photo.jpg may arrive as AVIF: the Content-Type header says what was actually sent.
Because one URL now has several correct answers, the response has to say so with Vary: Accept. That header tells every cache between the edge and the visitor, from a company proxy to the browser's own cache, that the answer depends on Accept. Without it, a shared cache can store the AVIF one visitor received and hand it to the next, whose browser cannot decode it.
The CDN's own cache follows the same rule, and here a detail matters. Accept strings differ between browsers and between versions of one browser, so a cache keyed on the raw header keeps a near-identical copy for every spelling. A well-built image CDN reduces the header to the decision it carries, AVIF, WebP or neither, and keeps one copy for each.
The other way is to make the choice in the HTML: a <picture> element lists an AVIF and a WebP <source>, and the browser takes the first type it supports. That needs no negotiation, but you produce, store and reference every variant yourself. With an image CDN the markup stays a plain <img>; <picture> remains the tool for art direction, when a phone should get a different crop rather than a smaller copy of the same picture.
Resizing through the URL
Format negotiation needs no change to your pages. Resizing does, because only the page knows how wide an image will be shown. Image CDNs take the size from the URL, usually as query parameters: photo.jpg?w=640 asks for a copy 640 pixels wide. A sensible service keeps the aspect ratio when you give one dimension, fits the image inside the box when you give both, and never enlarges an image beyond its original size.
Paired with srcset and sizes, one source file can serve every screen. You list a few widths of the same URL and say how wide the image is displayed, and the browser downloads the smallest copy that still looks sharp at the visitor's screen density. The image CDN produces each listed width the first time someone requests it and caches it from then on.
Keep the list short and fixed. Every distinct width is a separate conversion and a separate cache object, so five widths used across the whole site cache far better than whatever number each template happens to compute. Some services take further parameters, such as crop, quality or focal point, and each one multiplies the variants in the same way.
One source image, five widths: the browser picks the one it needs
<img
src="https://example.com/media/photo.jpg?w=960"
srcset="https://example.com/media/photo.jpg?w=320 320w,
https://example.com/media/photo.jpg?w=640 640w,
https://example.com/media/photo.jpg?w=960 960w,
https://example.com/media/photo.jpg?w=1280 1280w,
https://example.com/media/photo.jpg?w=1920 1920w"
sizes="(max-width: 720px) 100vw, 720px"
width="1920" height="1080" alt="">Every variant is its own cache object
An image CDN turns one file into a family. A photo requested in three formats at five widths is fifteen objects in the cache, each under its own key. Three things follow from that.
The cache key must carry the size. If a rule ignores the query string to raise the hit rate, ?w=320 and ?w=1920 share one key, and whichever size was requested first goes out to everyone. Keep the size parameters in the key, even where other parameters are dropped.
The first request pays for the conversion. A variant nobody has asked for yet is produced on demand: the edge fetches the original, encodes it and then caches the result. That one visitor waits a little longer; everyone after them gets the cached copy. For pages that must be fast on the very first view, a few requests after a deploy or a purge warm the cache in advance.
Purge and expiry apply to the whole family. When an original changes under the same name, every format and size made from it has to go. A purge by path prefix reaches them all; a purge of one exact URL can leave the resized copies behind. Switching conversion on is the easy case: when the format is part of the cache key, every converted copy is a new object and goes out from the first request. Only the copies already in visitors' browsers stay as they were until they expire there.
Quality and size: when a conversion loses
Every lossy format trades bytes for detail through a quality setting, and image CDNs choose a default that looks unchanged at normal viewing size. Set it lower and photos turn soft and blocky; set it higher and the saving shrinks. Text, sharp edges and flat colour show the damage first, which is why screenshots and logos need gentler treatment than photographs.
The format matters as much as the setting, and the winner changes with the image. On 5 October 2026 we ran three images through the image optimizer behind CDN.com.tr at its production settings and counted the bytes.
News photo, JPEG. Original 262,025 bytes; WebP 113,860; AVIF 86,936. The textbook case: AVIF carries the same picture in about a third of the original's bytes.
Panel screenshot, PNG. Original 105,078 bytes; optimized PNG 40,379; WebP 41,218; AVIF 27,942. A palette PNG is very good at flat colour and text, and here the WebP came out larger than it; AVIF still won.
Favicon, PNG, 16×16. Original 701 bytes; optimized PNG 483; WebP 314; AVIF 682. At this size the AVIF container's fixed overhead outweighs its better compression, and WebP wins clearly.
No format wins everywhere, and a conversion can produce a file heavier than the best version of the original. A good image CDN encodes, compares the bytes and sends the smaller file; one that converts blindly makes part of your images heavier and still reports them as optimized. Our AVIF vs WebP guide has the full measurements and the reasons behind them.
Image CDN or build-time optimization?
You can get the same formats without an image CDN. A build step, an upload hook or a plugin can convert every image once, write the variants next to the originals and let a plain CDN deliver them with <picture> markup. Which way is better depends on where your images come from.
Build-time wins on a site whose images live in the repository: a marketing site, documentation, a static app. The set is known in advance, each file can be tuned by hand, nothing is processed while a visitor waits, and what goes out is exactly what you tested.
An image CDN wins when images arrive faster than anyone can process them: product photos uploaded from a shop's admin, a newsroom's archive, a WordPress media library with years of uploads, pictures your users post. It also wins when the number of sizes grows with every layout, when a theme or a hosted CMS writes the markup for you, and when you would rather not run a converter on your own server.
The two combine well: hand-tuned hero graphics from the build, everything uploaded through the CMS from the image CDN. Logos and icons that are drawn rather than photographed are best kept as SVG either way: there is nothing to convert, and they stay sharp at every size.
Pitfalls to check before you switch one on
Most trouble with image CDNs comes from a handful of places, and each can be checked before a visitor notices.
A missing Vary. A response that changes with Accept but carries no Vary: Accept is the fault on this list that can show a visitor a broken image. Check what your CDN sends, and what any proxy in front of it passes on.
Size parameters outside the cache key. One size for everyone: request two widths of the same image and compare what comes back.
Unbounded parameters. If any width is accepted, anyone can request thousands of sizes and make you pay for each conversion. A fixed list of widths in your templates keeps your own pages to a few variants; requests made from outside are stopped only by a limit on the service side, such as a list of allowed widths or a rate limit.
Heavier outputs. Measure your own mix of images. If the service does not compare bytes, flat graphics and icons are where it hurts.
Formats that pass through. Animated GIFs, SVG files and images that are already WebP often go out unchanged; check which formats your service converts.
Processing cost and quotas. Encoding, AVIF above all, takes far more CPU than sending a cached file, and services meter it: per transformation, per processed byte or against a plan's quota. Read how yours counts before you switch every image on at once.
Stale copies. Images that browsers loaded before the switch stay in their caches until they expire, and no CDN purge reaches them. Judge the result with a fresh request, such as the checker below, rather than a reload.
Check what your site serves
The checker below shows what an image CDN, or the lack of one, does for a real page. It reads the page's HTML, takes up to 20 images from <img>, srcset, <picture> and og:image, and requests each one twice: once as a current browser asks (Accept: image/avif,image/webp,…) and once as a client that accepts anything (Accept: */*). It reads the first bytes of every answer to tell the real format, whatever the file name says, counts the bytes, and reports Vary and the cache status. A single image address works too.
If both requests get the original format for every image, nothing on the way converts your images. If the modern request gets AVIF or WebP but the answer carries no Vary: Accept, fix that first. The checker's own page explains every result and its limits.
Image optimization on CDN.com.tr
Image optimization is a switch for your whole account or a single delivery rule. The edge converts JPEG and PNG images to WebP, or to AVIF and WebP if you choose WebP + AVIF for the account, and each browser gets a format it accepts; browsers that accept neither get the image in its original format. With WebP + AVIF the answer comes from the same URL, with Vary: Accept; with WebP alone, browsers that accept WebP are redirected to a .webp copy. Either way your HTML keeps the same image URLs. At full size, a newly converted image goes out only when it is smaller than the original. If a conversion fails, the edge serves the original image instead. Processing counts toward your monthly quota.
The measurements above come from that optimizer. With WebP + AVIF the 262,025-byte news photo goes out as 86,936 bytes of AVIF, and the 105,078-byte panel screenshot as 27,942. Small or flat-colour PNG images up to one megapixel (icons, screenshots, illustrations) must also beat our own optimized PNG, so a browser that accepts WebP but not AVIF gets that screenshot as the 40,379-byte PNG, and the favicon goes out as the 314-byte WebP rather than the 682-byte AVIF.
Resizing works through the URL: add ?w=, ?h= or both to an image address. One value keeps the aspect ratio, both fit the image inside that box, and an image is never enlarged beyond its original size. Resized images are converted too, but they are not compared with the original. A rule keeps w and h in its cache key as long as it keeps the query string, which is the default; a rule that ignores every query parameter caches one size for all of them.
Copies the edge converted before the full-size comparison arrived stay as they were until they expire or are purged, and browsers that already loaded an image keep their copy until it expires in the browser. With WebP alone, the redirect to the .webp copy carries no Vary: Accept, and that is what the checker above reports; WebP + AVIF answers every browser from the one URL with Vary: Accept. AVIF counts toward the quota at a higher rate than WebP because encoding it takes more processing; the panel shows the current rate under the switch. The image optimization help topic walks through the switches, the format choice and the purge.
WordPress. On a WordPress site behind CDN.com.tr the edge does the converting: images from your media library are converted on their way through the CDN, so your server spends no CPU on encoding, no extra WebP or AVIF files are written to the library, and themes and page builders keep working because the image URLs do not change. When a site is not on our CDN, the free CDNTR plugin can convert images to WebP, and to AVIF where the server supports it, on the site's own server instead. Use one or the other: with edge conversion on, leave the plugin's local conversion off, so the edge works from your originals.
Frequently asked questions
What is the difference between a CDN and an image CDN?
A CDN stores copies of your files near your visitors and sends them unchanged. An image CDN does that too, and it also changes images on the way out: it converts them to a format each browser accepts, resizes them when the URL asks for a size, and caches every result. Many CDNs offer image optimization as a switch, so the two are often the same network with one feature turned on.
Does an image CDN change my original files?
No. The originals stay on your server or storage exactly as you uploaded them; the converted and resized copies are produced in the delivery path and live in the CDN's cache. Where converted images go out under the original URLs, switching conversion off brings the originals back as the cached copies expire or are purged.
Do I still need the <picture> element?
Not for formats. With an image CDN that negotiates, a plain <img> gets AVIF, WebP or the original depending on the browser, so the <source type="image/avif"> lines can go. Keep <picture> for art direction, when a small screen should get a different crop rather than a smaller copy of the same picture.
Can a converted image come out heavier?
Yes, heavier than the best version of the original, if the service converts without comparing. In our measurement a 16×16 favicon took 682 bytes as AVIF against 483 as optimized PNG and 314 as WebP, and a panel screenshot came out larger as WebP (41,218 bytes) than as optimized PNG (40,379). A good service checks the bytes and sends the smaller file. On CDN.com.tr a newly converted full-size image goes out only when it is smaller than the original, and a small or flat-colour PNG up to one megapixel only when it also beats our optimized PNG.
Is an image CDN worth it for WordPress?
Usually, because WordPress sites are where images pile up faster than anyone optimizes them. Edge conversion reaches the JPEG and PNG images in the whole media library, old uploads included, without a converter running on your server or extra files in wp-content/uploads. For a site that is not on a CDN, a plugin that converts locally, such as CDNTR, is the alternative.
How is image processing billed on CDN.com.tr?
It counts toward the account's monthly quota, like traffic; there is no separate package to buy. AVIF counts at a higher rate than WebP because encoding it takes more processing, and the panel shows the current rate under the switch.