The Best Free CDN for Images Options Compared

Key takeaways

• Filestack gives 1 GB free with nothing watermarked or restricted.
• imgix has no free plan, only a 30 day trial.
• Uploadcare’s free tier is personal use only, so you cannot ship on it.
• Transloadit watermarks every image on its free plan.
• Cloudinary meters in credits, not GB, so plans do not compare directly.

Free image CDN plans compared

Read this table first, because every number was taken from the vendor’s own pricing page in July 2026. Pricing moves, so check the current page before you commit to a plan.

Two rows in that table deserve a second look, because they are easy to miss and expensive to discover late.

Uploadcare’s free plan is generous on traffic, but it is also labeled personal use only, which means it cannot legally sit underneath a commercial product.

Transloadit gives you 5 GB a month free forever, but every image it returns on that plan carries a Transloadit watermark, which is fine for a prototype and not something you can ship.

Filestack’s free plan is the smallest on bandwidth at 1 GB and is capped at one team member. Nothing in it is watermarked or restricted to personal use, so what you build on it is what you ship.

How we evaluated these

We compared four things, and we weighed them in this order.

1. The real limit. Not the headline number, the one you hit first.
2. Whether you can ship it. A watermark or a personal use clause is a hard stop.
3. What happens past caching. Delivery is one step. Most teams also need resizing and format conversion.
4. The cost of leaving. How much code changes if you switch later.

We did not rank on raw network size, because every option here runs on a large global network and that number stopped being a differentiator years ago. If you want the wider infrastructure view, our best CDN providers content delivery network roundup covers the general purpose CDNs.

What to look for in a free cdn for images

A cache alone will not fix a slow page, because if your server sends a 3 MB PNG then the CDN just sends that same 3 MB PNG faster. The work that actually shrinks the page is resizing and format conversion.

Most sites still have not done this. The 2024 Web Almanac media chapter found WebP on only 12 percent of images across the crawled web, and AVIF on just 1 percent. JPEG still holds 32.4 percent, down from 40 percent in 2022. So the format win is real and largely unclaimed. MDN’s image format guide covers which browsers take what, and web.dev’s guide to image CDNs explains the pattern independently of any vendor.

So there are three things worth looking for beyond the cache itself.

• Automatic format negotiation. The CDN should send WebP to browsers that take it, and the original format to browsers that do not.
• Resize on the URL. You should not need a build step to get a 400 pixel thumbnail.
• A path past images. Most apps that accept images also accept PDFs and video eventually.

Our post on free image CDN website speed performance goes deeper on the speed side. For the setup steps we skip here, see free image cdn performance optimization delivery. If you are new to CDNs entirely, start with understanding free CDNs a developers guide.

Pricing once you outgrow free

Free tiers end, so here is the first paid step for each option, letting you see the cliff before you walk off it.

Filestack is not the cheapest line on that table and pretending otherwise would be silly. What the $69 provides is a larger surface, because the upload path, the processing engine, and delivery all sit behind a single key.

One detail matters more than it looks: on Filestack a transformation is cached for 30 days, and every view inside that window counts as one transformation. So 50,000 transformations is not 50,000 page views, it is 50,000 distinct image variants.

See the format switch happen

Here is one photo of a golden retriever puppy delivered two ways, from the same source file at the same 600 pixel width. Look at them, and then look at the file sizes underneath.

	Delivered as JPEG	Delivered as WebP
Content-Type	image/jpeg	image/webp
Dimensions	600 x 427	600 x 427
Size on the wire	41,259 bytes	29,628 bytes
File handle	57mEl6UeRNaEppLwJUJj	57mEl6UeRNaEppLwJUJj
Transform path	resize=width:600/output=format:jpg,quality:80	resize=width:600/output=format:webp,quality:80

Read the handle row again, because it is the same handle on both sides. You uploaded one file and the two deliveries are simply two different paths in front of it, so nothing was pre-generated and nothing extra was stored.

Neither variant above required a build step, and both are live, so right click either image and check the format yourself.

What the CDN knows about the file

You do not have to take the source numbers on faith, because the same URL pattern returns the stored file’s metadata as JSON, which is useful when you are debugging what actually landed.

curl -s “https://cdn.filestackcontent.com/metadata/57mEl6UeRNaEppLwJUJj”
# {“filename”:”golden-retriever-source.jpg”,”mimetype”:”image/jpeg”,
#  “size”:608073,”uploaded”:1784784574350.922,”writeable”:true}

curl -s “https://cdn.filestackcontent.com/imagesize/57mEl6UeRNaEppLwJUJj”
# {“height”:1552,”width”:2180}

So the source is a 594 KB camera JPEG while the WebP the browser actually receives is 29,628 bytes, which is the whole delivery story in two numbers.

Watch it resize

Width is just a number in the URL, so you change the number, get a different image, and store nothing extra.

width:200	width:600
7,472 bytes	29,628 bytes

At 1200 pixels that same URL returns 82,734 bytes, so a phone asks for the small one and a desktop asks for the large one, and your server never generated either of them.

One honest note on formats: we did not compare against PNG here, because PNG would flatter WebP unfairly. That same photo as a PNG is 437,352 bytes, more than ten times the JPEG, since PNG is the right format for flat graphics and screenshots rather than photographs. Compare like for like or the number means nothing.

Now the part that matters for delivery. Since you do not want to pick the format per browser by hand, ask for one URL two ways and watch the server decide.

# Same URL both times. The only difference is what the browser says it accepts.

curl -s -o /dev/null -w "%{content_type} %{size_download} bytes\n" \
  -H "Accept: image/webp" \
  "https://cdn.filestackcontent.com/auto_image/resize=width:1200/57mEl6UeRNaEppLwJUJj"
# image/webp 148140 bytes

curl -s -o /dev/null -w "%{content_type} %{size_download} bytes\n" \
  -H "Accept: image/jpeg" \
  "https://cdn.filestackcontent.com/auto_image/resize=width:1200/57mEl6UeRNaEppLwJUJj"
# image/jpeg 210896 bytes

Those are real responses from the same puppy photo above, at 1200 pixels wide. The auto_image task reads the Accept header and picks the format. A modern browser gets 145 KB of WebP. An older one still gets a working JPEG, no fallback logic in your code.

This is not a vendor trick. It is proactive content negotiation, defined in RFC 9110 section 12.1, and the Accept header it depends on is section 12.5.1 of the same spec. Any CDN can do it. The question to ask a vendor is whether it is on by default or something you configure per image.

You never wrote a build step, and you never stored a second copy.

Here is the whole loop in JavaScript. Install, upload, transform, deliver.

// npm install filestack-js@3.51.6
// Tested against filestack-js 3.51.6.
import * as filestack from 'filestack-js';

const client = filestack.init('YOUR_API_KEY');

async function uploadAndDeliver(file) {
  try {
    const res = await client.upload(file, {
      retry: 3, // retries on a flaky connection instead of failing the upload
      onProgress: (evt) => console.log(`${evt.totalPercent}%`),
    });

    // res looks like:
    // { handle: '57mEl6UeRNaEppLwJUJj', url: 'https://cdn.filestackcontent.com/...',
    //   filename: 'puppy.jpg', size: 608073, mimetype: 'image/jpeg' }

    return `https://cdn.filestackcontent.com/auto_image/resize=width:1200/${res.handle}`;
  } catch (err) {
    // upload errors expose the response so you can log something useful
    console.error('Upload failed:', err.message);
    throw err;
  }
}

That is the full path from a file the user picked to a URL that serves an optimized image. The chunked, resumable, retry-configurable upload behind client.upload is the file delivery story starting at the beginning, not at the cache.

What the same job costs to hand roll

You can of course build all of this yourself, and here is roughly what it takes.

// The DIY version, compressed to its outline.
import sharp from 'sharp';
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';

// 1. Accept the upload and stream it somewhere. Handle retries yourself.
// 2. Decide which variants you need, up front, because you must store each one.
const variants = [400, 800, 1200];

for (const width of variants) {
  for (const format of ['webp', 'jpeg']) {
    const buf = await sharp(input).resize({ width })[format]().toBuffer();
    await s3.send(new PutObjectCommand({ Key: `img/${id}-${width}.${format}`, Body: buf }));
  }
}
// 3. Write the <picture> element logic to pick a variant per browser.
// 4. Invalidate the CDN cache when the source changes.

That is six stored files per upload instead of one, plus the negotiation logic and the cache invalidation. It works, but it is also a service you now have to maintain. The tradeoff is real, and for a team with an infrastructure engineer it can be the right call.

Using an image cdn for wordpress

WordPress changes the shape of this slightly, because you are usually not calling an SDK at all. Instead you are rewriting URLs in the media library so that they point at the CDN.

The rule stays the same: pick something that rewrites to a transform URL rather than just a cached copy, so the theme can ask for the width it needs. If you serve a single full size image to a phone, a CDN will not save you.

Which is the best cdn for images for your stack

Here is the honest split between them.

• Pick Filestack if you want ingest, processing, and delivery from one key, and you expect to handle more than images later. The free tier is small on bandwidth, but nothing in it is crippled. Our Filestack CDN global file delivery architecture post covers how the delivery layer fits together. The deliver images product page has the full capability list.
• Consider Cloudinary if media is your product and you need deep video and image intelligence at scale. That is Cloudinary’s lane and they are very good in it. You will spend time learning the credit model.
• Consider Transloadit if you need broad raw format support or a portable, self hostable pipeline. Just budget for a paid plan from day one, because the free watermark rules out shipping.
• Consider Uploadcare if you want lean, security first delivery of user generated content and your use is genuinely personal, or you are ready to pay.
• Consider imgix if you have an existing image library in S3 and you only want a delivery and transformation layer over it. There is no free tier, so decide with the $25 plan in mind.

For a single page app, the delivery layer is only half the win. The other half is not blocking the main thread during upload, which we cover in Webpack file delivery optimization.

Where to go next

The puppy photo used in the format demo is public domain, from Wikimedia Commons.

Once delivery is sorted, the next question is usually what happens to a file between the upload and the CDN. That is where the loop closes. Files get scanned, converted, cropped to faces, or run through OCR before they are ever served, and that all happens behind the same key. Start with the file delivery workflow guide, then check the processing API docs for the task list.

carlc

Carl is a Product Marketing Manager at Filestack with four years of hands-on experience in React, JavaScript, Django, and Python. He bridges the gap between product and developer, translating how Filestack’s APIs and SDKs actually work into content that’s useful for the engineers building with them. His writing covers file handling workflows, upload integrations, and real-world implementation patterns, written from the perspective of someone who has built with these tools firsthand.

Read More →