An image CDN is a content delivery network built specifically for images. Instead of serving one fixed file to every visitor, it resizes, compresses, converts, and caches each image at the edge, then delivers the right version for the device and browser making the request.
This matters because images are usually the heaviest thing on a page. A hero photo exported at desktop resolution gets sent, in full, to a phone on a slow connection. Resizing at build time helps, but it locks you into a fixed set of variants and a rebuild every time the design changes.
Cosmic includes image hosting and an image CDN on every plan, including the free one. Upload an image once and every optimized variant is available immediately as a URL parameter. No build step, no separate CDN account, no image pipeline to maintain.
Start free or book a 15-minute walkthrough with our CEO.
How the Cosmic image CDN works
Every file you upload to a Cosmic bucket gets two URLs:
- A direct URL on
cdn.cosmicjs.com, which serves the original file exactly as uploaded. - An imgix URL on
imgix.cosmicjs.com, which accepts transformation parameters and is what you should use in production.
The imgix URL is returned on every media object and on every file metafield as imgix_url. Append parameters to it and the transformation happens at the edge, on first request, then caches.
https://imgix.cosmicjs.com/your-image.jpg?w=800&auto=format,compress
That single URL now serves an 800px-wide image, automatically converted to the best format the requesting browser supports and compressed. Change w=800 to w=400 and you have a different cached variant, with no re-upload and no second asset to track.
Uploading images to the CDN
Uploads go through the same SDK you use for content. Install it:
npm install @cosmicjs/sdk
Then push a file to the media library and read back the CDN URLs:
import { createBucketClient } from '@cosmicjs/sdk'; const cosmic = createBucketClient({ bucketSlug: process.env.COSMIC_BUCKET_SLUG!, readKey: process.env.COSMIC_READ_KEY!, writeKey: process.env.COSMIC_WRITE_KEY!, }); const { media } = await cosmic.media.insertOne({ media: file, // a File, Blob, or Buffer folder: 'product-shots', alt_text: 'Blue running shoe on a white background', }); media.url; // https://cdn.cosmicjs.com/... (original) media.imgix_url; // https://imgix.cosmicjs.com/... (transformable)
You can also drag files into the media library in the dashboard. Either way, the upload is the only step. Every size and format after that is a URL parameter.
How to get a CDN link for an image
If all you want is a hosted URL for an image you can paste into a site, an email, or a README, the flow is three steps and does not require writing any code:
- Create a bucket (the free plan is enough).
- Open Media in the dashboard and drag the file in.
- Copy either URL from the file's detail panel.
You now have two permanent CDN links for that image:
https://cdn.cosmicjs.com/your-image.jpg # original file, as uploaded https://imgix.cosmicjs.com/your-image.jpg # same image, transformable https://imgix.cosmicjs.com/your-image.jpg?w=600 # 600px wide, cached at the edge
Use the imgix.cosmicjs.com link anywhere you want control over size and format. Use the cdn.cosmicjs.com link when you need the untouched original, for example a downloadable asset or a print-resolution file.
The link does not expire and does not change when you edit the surrounding content. If you need to swap the picture later, upload a new file and update the reference, so the old URL stays valid for anything already pointing at it.
Fetching and rendering optimized images
Fetch an object and read its imgix_url:
import { createBucketClient } from '@cosmicjs/sdk'; const cosmic = createBucketClient({ bucketSlug: process.env.COSMIC_BUCKET_SLUG!, readKey: process.env.COSMIC_READ_KEY!, }); const { object: post } = await cosmic.objects .findOne({ type: 'blog-posts', slug: 'hello-world' }) .props(['title', 'metadata.image']); // Build an optimized, format-negotiated URL const hero = `${post.metadata.image.imgix_url}?w=1200&auto=format,compress`;
Render a responsive image with a proper srcset, so mobile visitors never download a desktop-sized file:
const base = post.metadata.image.imgix_url; export function Hero() { return ( <img src={`${base}?w=1200&auto=format,compress`} srcSet={[400, 800, 1200, 1600] .map((w) => `${base}?w=${w}&auto=format,compress ${w}w`) .join(', ')} sizes="(max-width: 768px) 100vw, 1200px" alt={post.title} loading="lazy" width={1200} height={630} /> ); }
Four variants of one asset, zero extra uploads. If you are working in React or Next.js, the same pattern drops straight into next/image via a custom loader. See Headless CMS for React for the wider setup, or the best headless CMS for React and Next.js if you are still choosing a content layer for a Next.js build.
You can run that exact snippet against your own media on the free plan, which includes the image CDN and needs no credit card. Create a bucket and upload one image, then append ?w=400&auto=format,compress to its imgix_url and watch the variant cache at the edge.
Image optimization and resizing parameters
Cosmic media URLs are served through imgix, so the imgix rendering API is available on every imgix_url. Parameter behaviour described below was checked against the imgix auto parameter reference on September 25, 2026. The parameters that do the most work:
| Parameter | Effect |
|---|---|
w, h | Resize to a target width or height |
auto=format | Automatic content negotiation. Serves a modern format such as AVIF or WebP where the browser supports it, and falls back to JPEG or PNG where it does not |
auto=compress | Reduces file size. Sets the quality standard to 45, strips embedded metadata, and serves PNG for images with transparency or JPEG for everything else |
auto=format,compress | Both at once, comma separated. auto=format content negotiation takes priority over the format auto=compress would pick, so you get AVIF or WebP with compression still applied |
fit=crop + crop=faces | Crop to a focal point, including detected faces |
q | Override the quality level |
dpr | Serve a higher pixel density variant for retina displays |
blur, sharpen, sat | Visual adjustments at request time |
Each unique combination of parameters is generated once, then cached at the edge, so the cost of a new variant is one slow request rather than a rebuild.
Checking which format is actually being served
auto=format negotiates per request, so the way to confirm it is working is to look at the response rather than the URL. Open your browser's network panel, load the page that renders the image, and check the Content-Type response header. Expect image/avif on a current Chrome or Safari, image/webp on a browser without AVIF support, and image/jpeg or image/png as the final fallback.
Two documented behaviours in the imgix auto parameter reference, both read on September 25, 2026, catch people out here:
- Pasting the image URL straight into a Firefox tab is not a valid test. From Firefox 66 onward, automatic content negotiation only runs when the image is being rendered on a webpage, not when a single image is opened on its own. You will get the fallback format and conclude the parameter is broken when it is working correctly.
- Safari behaviour changed in September 2024. imgix previously served WebP to Safari under
auto=formatfor stability reasons, and now serves AVIF to Safari 16.4 and later. If your own code carries a browser-support table that still maps Safari to WebP, it is out of date.
One edge case worth knowing if your library contains animated GIFs with transparency: Safari 16.4 and later reports AVIF support, so auto=format converts those GIFs to AVIF, which does not preserve GIF-style animation with transparency. The simplest workaround is to leave auto=format off GIF requests in your application logic.
How much smaller do images actually get?
Savings depend entirely on the source image, so treat any single headline number with suspicion, including ours. A photograph with smooth gradients compresses dramatically under AVIF. A flat-color logo or a screenshot with hard edges may barely move, and can occasionally get larger. imgix documents the same caveat for its own parameter: AVIF file-size savings are a statistical average across requests rather than a per-image guarantee.
The honest way to size the win is to measure your own library. Take your five heaviest images, request each one at the width it is actually displayed at with auto=format,compress, and compare the transferred bytes in your browser's network panel against what you ship today. That number is the only one that describes your site.
How to choose the best image CDN
Most image CDNs will resize and convert competently. The differences that actually show up on an invoice or in a migration are these:
How the pricing meter works. Vendors bill on different units: stored images, transformations, delivered images, bandwidth, or a blended credit. Two providers can look similar per month and diverge by an order of magnitude once a redesign generates a new set of variants across your whole library. Work out which unit your usage is heaviest in, then price that unit specifically.
Whether transformations are metered separately from delivery. If every new width counts as a billable transformation, a responsive srcset with four breakpoints is four chargeable events per image. If transformations are bundled, breakpoints are effectively free and you can be generous with them.
Whether it is bundled with where your content already lives. A standalone image CDN is another account, another set of keys, another billing relationship, and a second place your assets can drift out of sync with your content. If your CMS already ships an image CDN, that whole category of integration work disappears.
Format negotiation you do not have to configure. Automatic AVIF and WebP negotiation should be a single parameter. If you are maintaining browser-support logic yourself in application code, the CDN is not doing its job.
Metadata handling, especially alt text. Alt text belongs on the asset, not on each page that references it. If the CDN or media library cannot store it centrally, you will end up rewriting the same description in a dozen templates.
A free tier you can actually evaluate on. Free plans vary enormously in what they meter. Check the file count, storage, request, and bandwidth allowances together, because a generous storage limit paired with a tiny request allowance will still stop you in week one.
The exit path. Check that you can retrieve original, untransformed files and that URLs are stable. An image layer you cannot leave is a long-term liability, however good the transforms are.
How the major image CDNs meter you
Every figure below was read from the vendor's own page on October 5, 2026. Pricing moves, so check the linked source before you budget against it.
| Provider | What the meter actually counts | Free tier, as published |
|---|---|---|
| Cloudinary | A blended "credit". One credit buys 1,000 transformations or 1 GB of managed storage or 1 GB of image bandwidth, so all three draw down the same pool | 25 credits per month, 3 users. Plus is $99/month for 225 credits, Advanced $249/month for 600 |
| ImageKit | Bandwidth, with storage metered separately | 20 GB bandwidth and 3 GB storage per month, 2 users. Automatic AVIF is not listed on Free or on Lite ($9/month); it appears from Pro ($89/month) upward |
| Cloudflare Images | Three separate meters: transformations, images stored, images delivered | 5,000 unique transformations per month, and only for images stored outside Images, such as in R2 or your own origin. Beyond that it is $0.50 per 1,000 transformations, $5 per 100,000 images stored, $1 per 100,000 delivered |
| Cosmic | Files stored, storage, API requests, and bandwidth, counted per plan. Transformations are not a separate meter | Free plan: 1,000 files, 1 GB storage, 1 GB bandwidth, image CDN included, no credit card |
The transformation meter is where these models diverge in practice. Under a blended credit or a per-transformation charge, a responsive srcset at four breakpoints is four billable events for every image, and a redesign that shifts those breakpoints re-bills the entire library. Cosmic does not meter transformations, so breakpoints cost nothing extra and you can be as generous with srcset as the layout needs.
Cosmic covers these by making the image CDN part of the content platform rather than a separate purchase: one upload, transformations by URL parameter, alt text on the media record, and the original file always retrievable at its cdn.cosmicjs.com URL.
Using Cosmic for image hosting and CDN delivery
Image hosting and image delivery are the same job here. Cosmic stores the original file, serves it from cdn.cosmicjs.com, and serves every transformed variant from imgix.cosmicjs.com. Storage, transformation, and edge delivery come from one upload, with no host-plus-CDN wiring to maintain between them.
You also do not have to run your whole site on Cosmic to use it. A common pattern:
- Create a free bucket.
- Upload images to the media library, or push them via the SDK.
- Reference the
imgix_urlwith parameters anywhere, including a site running on another platform.
This works as a drop-in image layer for an existing app, and it means the assets stay queryable through the same REST API as the rest of your content. If you are mapping out how images fit alongside the rest of your schema, content modeling covers how file and media fields are structured.
How much does an image CDN cost?
The image CDN is included on every plan, free included. Plan differences are about scale and team size, not CDN access.
| Plan | Price | Buckets | Team members | Objects |
|---|---|---|---|---|
| Free | $0/mo | 1 | 2 | 1,000 |
| Builder | $99/mo | 2 | 3 | 5,000 |
| Team | $299/mo | 3 | 5 | 20,000 |
| Business | $499/mo | 5 | 10 | 50,000 |
| Enterprise | Custom | Custom | Custom | Custom |
Additional team members are $29/user/month, and additional buckets are $29/bucket/month. Yearly billing saves 10%.
If you are evaluating Cosmic specifically for image hosting, these are the limits that will actually bind:
| Plan | Media files | Media storage | Media requests/mo | Media bandwidth/mo |
|---|---|---|---|---|
| Free | 1,000 | 1 GB | 1M | 1 GB |
| Builder | 5,000 | 2 GB | 2M | 10 GB |
| Team | 20,000 | 3 GB | 3M | 100 GB |
| Business | 50,000 | 10 GB | 10M | 500 GB |
| Enterprise | Custom | Custom | Custom | Custom |
Note that transformations are not a separate billable line. A new width or format is a media request against the allowance above, not a per-transformation charge, so a responsive srcset does not carry its own price tag.
Going over does not cut you off. Overages are billed at the end of the month: $0.50 per 1,000 media files, $0.069 per GB of media storage, $0.225 per 10k media requests, and $0.30 per GB of media bandwidth.
One thing to know before you plan a budget: Webhooks, Localization, Revision History, and Automatic Backups are not included in the plan prices above. Each is a $99/month add-on, or $199/month for all four bundled. Automatic Backups includes a 14-day free trial; the other three do not advertise one. None of them are required to use the image CDN.
Frequently asked questions
What is an image CDN?
A content delivery network that transforms images in addition to caching them. A standard CDN caches whatever file you gave it. An image CDN generates the correctly sized and correctly formatted variant per request, then caches that.
What is the best image CDN?
There is no single answer that holds for every project, and any page handing you one is selling something. The choice turns on where your content already lives, how the vendor meters transformations against delivery, and whether you can get original files back out. The criteria in the section above are the ones that actually change the answer. If your content already sits in a headless CMS that ships an image CDN, using it removes an entire integration, a second set of API keys, and a second invoice, which is why Cosmic includes one on every plan including Free.
Do I need an image CDN if I already use a CDN?
A general-purpose CDN solves distance and caching. It does not solve a 3MB hero image being sent to a phone. If your images are resized at build time or not at all, an image CDN is doing work your existing CDN cannot.
Can I use Cosmic for image hosting?
Yes. A Cosmic bucket is image hosting and an image CDN in the same product. Upload a file and you get a permanent URL on cdn.cosmicjs.com for the original plus a transformable URL on imgix.cosmicjs.com for every variant. Storage, file count, request, and bandwidth allowances per plan are in the table above.
Is the Cosmic image CDN free?
The image CDN is available on the free plan along with every paid plan. The free plan includes 1,000 media files, 1 GB of media storage, 1M media requests per month, and 1 GB of media bandwidth per month. No credit card is required to create one. These allowances were read from the Cosmic pricing page on September 25, 2026. See pricing for the current per-plan numbers.
Can I use it without migrating my CMS?
Yes. Upload assets to a Cosmic bucket and reference the imgix URLs from any application. Nothing else has to move.
Does Cosmic support GraphQL for querying media?
No. Cosmic offers a REST API and the official JavaScript and TypeScript SDK, @cosmicjs/sdk. If GraphQL is a hard requirement for your stack, Cosmic is not the right fit.
How do I set alt text?
Alt text lives on the media record itself, so every object that references the image inherits the description. Set it once in the media library rather than per-page.
Does resizing count as a separate charge?
No. Transformations are not metered as their own billable unit. Requests for transformed variants count against your plan's media request allowance, the same as any other media request.
Can I serve images to a site that is not built with Cosmic?
Yes. The imgix.cosmicjs.com URLs are public and work from any origin, so you can use a Cosmic bucket purely as an image layer for a WordPress site, a Rails app, or a static site on another host.
Related
- Headless CMS: the wider platform the image CDN is part of
- React CMS: fetching and rendering Cosmic content in React
- Best headless CMS for React and Next.js: how the content layer options compare if you are still choosing one
- Content modeling: how file and media fields fit into a schema
- Pricing: current plan limits including media allowances
Start serving optimized images
Create a bucket, upload an image, and add ?w=800&auto=format,compress to the URL. That is the whole evaluation.