# Image CDN Guide: Which CDN I Use and Why (2026) — Complete Documentation
> I've tested BunnyCDN, Cloudflare Images, ImageKit, and more across dozens of websites. Here's my honest breakdown of the best image CDNs, real pricing data, and the setup that saves me thousands in bandwidth every year.
This is the full content of every docs and tools page on theimagecdn.com, concatenated for agents that prefer a single-file corpus. The canonical page index is at https://theimagecdn.com/llms.txt and the site root is https://theimagecdn.com/.
## Table of Contents
- [WebP vs AVIF vs JPEG - Which Image Format Should You Use in 2026?](#webp-vs-avif-vs-jpeg-which-image-format-should-you-use-in-2026)
- [Paid Image CDN Options 2026: Real Pricing, Billing Models & Cost Math](#paid-image-cdn-options-2026-real-pricing-billing-models-cost-math)
- [Lossless Image Formats for the Web: PNG, WebP, AVIF, JPEG XL Compared](#lossless-image-formats-for-the-web-png-webp-avif-jpeg-xl-compared)
- [Image Formats Explained: JPEG, PNG, WebP, AVIF, SVG, GIF, JPEG XL & HEIC](#image-formats-explained-jpeg-png-webp-avif-svg-gif-jpeg-xl-heic)
- [JPEG XL in 2026: Back in Chrome, Still Not Ready for Your Website](#jpeg-xl-in-2026-back-in-chrome-still-not-ready-for-your-website)
- [Best Image CDNs for PNG Files - Transparency, WebP & AVIF (2026)](#best-image-cdns-for-png-files-transparency-webp-avif-2026)
- [Image CDNs for Startups: $0-15/Month Plans That Scale in 2026](#image-cdns-for-startups-0-15-month-plans-that-scale-in-2026)
- [Best Image CDN for Small Ecommerce Websites in 2026: Product Images, Cost, and Speed](#best-image-cdn-for-small-ecommerce-websites-in-2026-product-images-cost-and-speed)
- [Do Image CDNs Improve LCP? Test Setup, Results, and Fixes](#do-image-cdns-improve-lcp-test-setup-results-and-fixes)
- [Best Free Image CDN in 2026: Real Limits, Failure Modes & Upgrade Paths](#best-free-image-cdn-in-2026-real-limits-failure-modes-upgrade-paths)
- [Cloudinary Pricing Explained (2026): Credits, Free Tier & What You Actually Pay](#cloudinary-pricing-explained-2026-credits-free-tier-what-you-actually-pay)
- [BunnyCDN Pricing Explained (2026): What You Actually Pay for CDN + Optimizer](#bunnycdn-pricing-explained-2026-what-you-actually-pay-for-cdn-optimizer)
- [Can Image CDNs Convert Image Formats? Yes - Here Is How](#can-image-cdns-convert-image-formats-yes-here-is-how)
- [Best Image CDN in 2026: 9 Providers Compared by Pricing, Features, and Use Case](#best-image-cdn-in-2026-9-providers-compared-by-pricing-features-and-use-case)
- [ImageKit Pricing: Free, Lite and Pro Plan Limits Compared](#imagekit-pricing-free-lite-and-pro-plan-limits-compared)
- [ImageKit Coupon Code 2026 — The Real Discounts (No Fake Codes)](#imagekit-coupon-code-2026-the-real-discounts-no-fake-codes)
- [How to Migrate Images to a CDN Without Losing SEO](#how-to-migrate-images-to-a-cdn-without-losing-seo)
- [Beyond LCP: How Images Cause CLS and Hurt INP](#beyond-lcp-how-images-cause-cls-and-hurt-inp)
- [Why Your Website Needs an Image CDN](#why-your-website-needs-an-image-cdn)
- [Smart Cropping with Image CDNs - How Auto Crop Actually Works](#smart-cropping-with-image-cdns-how-auto-crop-actually-works)
- [Image CDN vs Traditional CDN: What Actually Changes](#image-cdn-vs-traditional-cdn-what-actually-changes)
- [Do I Need a CDN? A Practical Decision Framework](#do-i-need-a-cdn-a-practical-decision-framework)
- [Best WordPress Image Optimization Plugins in 2026: Compression, WebP/AVIF & Pricing Compared](#best-wordpress-image-optimization-plugins-in-2026-compression-webp-avif-pricing-compared)
- [Is PNG Lossy or Lossless? The Direct Answer](#is-png-lossy-or-lossless-the-direct-answer)
- [HEIC vs JPG - Which Should You Use in 2026? (Quality, Size & Compatibility)](#heic-vs-jpg-which-should-you-use-in-2026-quality-size-compatibility)
- [How to Minimize Cloudflare Images Costs (2026): 7 Practical Levers](#how-to-minimize-cloudflare-images-costs-2026-7-practical-levers)
- [EWWW Image Optimizer Review - Is It Still Worth Using in 2026?](#ewww-image-optimizer-review-is-it-still-worth-using-in-2026)
- [Cloudflare Images Pricing 2026: Free vs Paid, Remote Images & Real Cost Math](#cloudflare-images-pricing-2026-free-vs-paid-remote-images-real-cost-math)
- [BunnyCDN Coupon Code 2026 — $5 Free Credit + Honest Stacking Guide](#bunnycdn-coupon-code-2026-5-free-credit-honest-stacking-guide)
- [7 Best Image CDNs for WordPress in 2026: Pricing, Plugins, and Setup](#7-best-image-cdns-for-wordpress-in-2026-pricing-plugins-and-setup)
- [Image CDN for Next.js: Loaders, Static Export & Cost Math (2026)](#image-cdn-for-next-js-loaders-static-export-cost-math-2026)
- [Cloudinary vs ImageKit vs BunnyCDN: Which Image CDN Should You Use in 2026?](#cloudinary-vs-imagekit-vs-bunnycdn-which-image-cdn-should-you-use-in-2026)
- [Why Your Image CDN Is Not Improving LCP: 7 Configuration Mistakes](#why-your-image-cdn-is-not-improving-lcp-7-configuration-mistakes)
- [Progressive JPEG vs Baseline JPEG - Which Should You Use?](#progressive-jpeg-vs-baseline-jpeg-which-should-you-use)
- [Lossy vs Lossless Compression - When to Use Each for Web Images](#lossy-vs-lossless-compression-when-to-use-each-for-web-images)
- [Lazy Loading Images with an Image CDN - The Practical Guide](#lazy-loading-images-with-an-image-cdn-the-practical-guide)
- [Will an Image CDN Make My Website Faster? Usually, If Images Are The Bottleneck](#will-an-image-cdn-make-my-website-faster-usually-if-images-are-the-bottleneck)
- [Quick CDN Startup Guide: Set Up BunnyCDN the Right Way](#quick-cdn-startup-guide-set-up-bunnycdn-the-right-way)
- [Free vs Paid Image CDNs: When Free Stops Being Enough](#free-vs-paid-image-cdns-when-free-stops-being-enough)
- [CDN for Pictures: What It Means and How to Set It Up](#cdn-for-pictures-what-it-means-and-how-to-set-it-up)
- [Can Using an Image CDN Hurt Your SEO? Only If You Misconfigure It](#can-using-an-image-cdn-hurt-your-seo-only-if-you-misconfigure-it)
- [Free Image Tools: Online Converters and Optimizers](#free-image-tools-online-converters-and-optimizers)
- [Free WebP to PNG Converter - Browser-Based, No Upload Required](#free-webp-to-png-converter-browser-based-no-upload-required)
- [Free PNG to WebP Converter - Browser-Based, No Upload Required](#free-png-to-webp-converter-browser-based-no-upload-required)
- [Free PDF Compressor and Analyzer - Browser-Based, No Upload](#free-pdf-compressor-and-analyzer-browser-based-no-upload)
- [Free JPG to PDF Converter - Browser-Based, No Upload Required](#free-jpg-to-pdf-converter-browser-based-no-upload-required)
- [JPEG to WebP Converter - Free, Local, Batch](#jpeg-to-webp-converter-free-local-batch)
- [Free Bulk Image Compressor - Browser-Based WebP, JPEG, PNG Output](#free-bulk-image-compressor-browser-based-webp-jpeg-png-output)
- [Free HEIC to JPG Converter - Browser-Based iPhone Photo Converter](#free-heic-to-jpg-converter-browser-based-iphone-photo-converter)
---
## WebP vs AVIF vs JPEG - Which Image Format Should You Use in 2026?
A practical comparison of WebP, AVIF, and JPEG with current browser support, compression tradeoffs, encoding speed, transparency, HDR, and clear recommendations by use case.
WebP is the safest modern default. AVIF usually gives the smallest photo files. JPEG is the fallback that works everywhere. That is the real answer, but the best choice still depends on whether you care more about compression, encoding speed, browser reach, or simplicity.
**TL;DR:** For most websites in 2026, serve **AVIF first**, **WebP second**, and **JPEG as fallback** through an [image CDN format-conversion setup](/docs/can-image-cdn-convert-formats). If you are choosing only one modern format manually, choose **WebP**. If you run a high-traffic photo, ecommerce, or media site and derivatives are cached, add **AVIF**. Keep **JPEG** for legacy fallback, email, and workflows where every tool must open the image.
Short answer: use WebP as the practical default, AVIF as the compression upgrade, and JPEG as the fallback.
| Situation | Best choice | Why |
| | --- |
| Normal blog or business website | **WebP + JPEG fallback** | Strong savings, broad support, fast encoding |
| Ecommerce product photos | **AVIF + WebP + JPEG** | Smaller photo files can help product pages load faster |
| Photography or portfolio site | **AVIF + WebP fallback** | AVIF preserves gradients and detail well at smaller sizes |
| User-uploaded images | **WebP** | Faster to generate than AVIF for real-time workflows |
| Existing JPEG library | **Keep JPEG source, serve WebP/AVIF derivatives** | Avoid destructive source replacement |
| Email, old CMS, legacy tools | **JPEG** | Compatibility beats compression |
| Transparent graphics | **WebP or AVIF, not JPEG** | JPEG has no alpha channel |
| HDR or wide-gamut images | **AVIF** | JPEG and WebP are 8-bit sRGB-oriented formats |
If I had to pick one manual conversion target for a small site, I would pick WebP. The file-size win over JPEG is meaningful, support is strong, and the tooling is boring in a good way.
If I had an image CDN or a build pipeline that caches generated files, I would add AVIF. The compression is better, but the encode cost is the catch. Cached AVIF is useful. Uncached AVIF on every request is pain.
For a broader format map beyond these three, read [image formats explained](/docs/image-formats-explained).
As of June 2026, this is the practical comparison.
Canonical source: [https://theimagecdn.com/docs/webp-vs-avif-vs-jpeg](https://theimagecdn.com/docs/webp-vs-avif-vs-jpeg) — Markdown: [https://theimagecdn.com/docs/webp-vs-avif-vs-jpeg.md](https://theimagecdn.com/docs/webp-vs-avif-vs-jpeg.md)
---
## Paid Image CDN Options 2026: Real Pricing, Billing Models & Cost Math
BunnyCDN, ImageKit, Cloudflare Images, Sirv, Imgix, Uploadcare, and Gumlet compared by real 2026 pricing, billing model, free-plan cliff, and monthly cost math.
Paid image CDNs do not all charge for the same thing. BunnyCDN charges bandwidth plus a flat Optimizer fee. ImageKit charges plan plus overage. Cloudflare Images charges unique transformations or hosted image delivery. Imgix charges credits. Uploadcare charges operations, traffic, and storage. That is why the cheapest provider at 500 images may not be the cheapest provider at 50,000 images.
**TL;DR:** For most websites, [BunnyCDN](https://try.sunnysah.com/BunnyCDN) is still the best paid value: **$0.01/GB** in Europe and North America plus **$9.50/month** for Bunny Optimizer. ImageKit Lite is the better $9/month developer pick when you want APIs and no per-transform meter. Cloudflare Images can be cheaper for small Cloudflare-native sites, but responsive variants decide the bill.
Short answer: **$10-15/month** is enough for most sites.
The expensive plans are not always faster. They usually include other things: DAM storage, upload widgets, video processing, AI transformations, enterprise support, or file management.
Here is the practical pricing overview as of June 2026.
| Provider | Billing Model | Entry Paid Price | Real Cost for a Medium Site |
| | --- | --- |
| **BunnyCDN** | Bandwidth + flat Optimizer | $0.01/GB + $9.50/mo | **$10-15** |
| **ImageKit** | Plan + bandwidth/storage overage | $9/mo Lite | **$9-20** |
| **Cloudflare Images** | Unique transformations or hosted delivery | Paid usage after first 5,000 transforms | **$0-25** |
| **Sirv** | Storage + transfer tiers | $19/mo Business | **$19+** |
| **Imgix** | Credit bundles | $25/mo Starter | **$25-75** |
| **Gumlet** | Bandwidth tiers | ~$32/mo Growth | **$32+** |
| **Uploadcare** | Operations + traffic + storage | $66/mo annual equivalent Pro | **$66-79+** |
That table is why I do not like generic "best CDN" lists.
If you only need image compression and responsive delivery, the $75/month tools are usually overkill. If you are building a marketplace with user uploads, moderation, file processing, and a media library, the cheap CDN may be the wrong product.
Canonical source: [https://theimagecdn.com/docs/paid-cdn-options](https://theimagecdn.com/docs/paid-cdn-options) — Markdown: [https://theimagecdn.com/docs/paid-cdn-options.md](https://theimagecdn.com/docs/paid-cdn-options.md)
---
## Lossless Image Formats for the Web: PNG, WebP, AVIF, JPEG XL Compared
A practical guide to lossless image formats for the web: PNG, lossless WebP, AVIF lossless, JPEG XL, GIF, TIFF, and when each one actually makes sense.
Lossless image formats preserve the original pixels exactly. That is what you want for screenshots, logos, diagrams, UI mockups, transparent graphics, and source files. For normal web delivery in 2026, the practical answer is simple: use lossless WebP when you can, keep PNG as the fallback, and save JPEG XL for archival workflows until browser support improves.
**TL;DR:** **WebP lossless is the best practical lossless format for the web** because it preserves pixels, supports transparency, and has [95.97% global browser support](https://caniuse.com/webp). **PNG remains the safest fallback** because it works everywhere. **JPEG XL is technically excellent for archival and lossless JPEG recompression**, but [13.6% browser support](https://caniuse.com/jpegxl) — all of it partial, all of it Safari — is not enough for primary web delivery. **AVIF lossless exists**, but you should test it per image because its lossy mode is much stronger than its lossless story.
A lossless image format compresses an image without discarding pixel data. Decode the file and you get the same pixels back.
That is different from lossy compression. A lossy format such as JPEG, lossy WebP, or AVIF can make photos much smaller by throwing away detail the eye is less likely to notice. That is great for delivery, but it is not exact.
Lossless compression is the right choice when exactness matters:
- screenshots
- UI mockups
- logos
- diagrams
- icons
- transparent graphics
- source files you may edit later
- images with small text or sharp edges
The catch is file size. Lossless compression cannot throw anything away, so it usually cannot compete with lossy formats for photos. A lossless photo may be several times heavier than a visually identical lossy WebP or AVIF.
For the broader tradeoff, read [lossy vs lossless compression](/docs/lossy-vs-lossless-compression).
Canonical source: [https://theimagecdn.com/docs/lossless-image-formats](https://theimagecdn.com/docs/lossless-image-formats) — Markdown: [https://theimagecdn.com/docs/lossless-image-formats.md](https://theimagecdn.com/docs/lossless-image-formats.md)
---
## Image Formats Explained: JPEG, PNG, WebP, AVIF, SVG, GIF, JPEG XL & HEIC
A practical 2026 guide to JPEG, PNG, WebP, AVIF, SVG, GIF, JPEG XL, and HEIC. Learn which image format to use for photos, logos, screenshots, animations, and web performance.
The best image format is not one format. It depends on the job. Use AVIF or WebP for photos, SVG for logos and icons, PNG for screenshots and pixel-perfect graphics, animated WebP for short loops, and JPEG as the fallback that still works everywhere.
**TL;DR:** For a normal website in 2026, serve **AVIF first**, **WebP second**, and **JPEG or PNG as fallback**. Use **SVG** for logos, icons, charts, and simple illustrations. Keep **PNG** for screenshots, transparent graphics, and images with sharp text. Avoid **GIF** unless you need legacy animation support. Do not serve **HEIC** directly on the open web. Treat **JPEG XL** as promising, but not ready as your only production format because browser support is still partial.
Short answer: use the format that matches the image, not the newest format you have heard about.
| Image type | Best default | Fallback | Why |
| | --- | --- |
| Photos, product images, hero images | **AVIF** | WebP -> JPEG | Smallest files when cached properly |
| General blog images | **WebP** | JPEG | Great size savings with simpler encoding |
| Logos and icons | **SVG** | PNG | Sharp at every size, usually tiny |
| Screenshots and UI images | **PNG** or lossless WebP | PNG | Preserves text and sharp edges |
| Transparent graphics | **WebP** or PNG | PNG | Keeps alpha transparency |
| Short animations | **Animated WebP** | GIF | Much better quality per byte |
| iPhone uploads | Convert **HEIC** | JPEG/WebP/AVIF | HEIC is not a cross-browser web format |
| Archival JPEG storage | **JPEG XL** | Original JPEG | Useful for storage, weak for web delivery |
The honest answer for most site owners is even simpler: use an image CDN and stop hand-picking formats for every browser. The CDN reads the `Accept` header, serves AVIF or WebP when supported, and falls back when needed. I covered that workflow in [can image CDNs convert image formats?](/docs/can-image-cdn-convert-formats).
If you are doing manual optimization, start with the highest-impact images first: homepage hero image, product gallery images, above-the-fold article images, and any image that becomes the Largest Contentful Paint element. The [LCP image CDN guide](/docs/do-image-cdns-…
Canonical source: [https://theimagecdn.com/docs/image-formats-explained](https://theimagecdn.com/docs/image-formats-explained) — Markdown: [https://theimagecdn.com/docs/image-formats-explained.md](https://theimagecdn.com/docs/image-formats-explained.md)
---
## JPEG XL in 2026: Back in Chrome, Still Not Ready for Your Website
JPEG XL returned to Chrome behind a flag, and Safari has shipped it since 17. But zero browsers enable it by default, and the best benchmarks come from the company that co-created it. Here is the honest state of JXL.
Short answer: JPEG XL is the best image format you should not use on your website yet. It is technically excellent, it is genuinely back in Chrome, and **zero browsers enable it by default** — including Chrome 151, the current stable release.
**TL;DR:** JPEG XL (`.jxl`, ISO/IEC 18181) compresses better than AVIF and WebP and can shrink existing JPEGs by ~20% with bit-exact reversibility. But Can I Use puts it at 13.6% support, and every point of that is *partial* support in Safari. Chrome and Firefox ship it behind flags. Serve AVIF with a WebP or JPEG fallback instead.
This page exists because most of what is currently written about JPEG XL is wrong in the same direction: too optimistic. You will find articles claiming 20–25% browser support, or that Chrome enabling it by default is imminent, or quoting a specific H2-2026 ship date. None of those are supported by primary sources.
Here is what the actual documentation says.
JPEG XL is a royalty-free image format standardised as **ISO/IEC 18181**, developed by the JPEG committee from two competing 2018 proposals: Google's PIK and Cloudinary's FUIF. The final format is, in Google's own words, a "best-of-both-worlds compromise" between them.
It uses the `.jxl` extension and the `image/jxl` MIME type. Per [jpeg.org](https://jpeg.org/jpegxl/), it handles "lossy encoding, lossless encoding, and lossless recompression of existing JPEG images", plus "animation, alpha channels, layers, thumbnails, lossless and progressive coding" and "wide colour gamut as well as high dynamic range and high bit depth images".
That is an unusually broad feature list. JPEG XL is designed to replace JPEG, PNG, and GIF with one codec rather than sit alongside them, which is a different ambition from [WebP or AVIF](/docs/webp-vs-avif-vs-jpeg).
The reference implementation, `libjxl`, is BSD-licensed and free.
Canonical source: [https://theimagecdn.com/docs/jpeg-xl-explained](https://theimagecdn.com/docs/jpeg-xl-explained) — Markdown: [https://theimagecdn.com/docs/jpeg-xl-explained.md](https://theimagecdn.com/docs/jpeg-xl-explained.md)
---
## Best Image CDNs for PNG Files - Transparency, WebP & AVIF (2026)
A practical comparison of the best image CDNs for PNG files, including Bunny, ImageKit, Cloudflare, and Cloudinary for transparency, screenshots, logos, and WebP/AVIF delivery.
PNG is the right source format for logos, UI screenshots, icons, diagrams, and transparent graphics. It is also one of the easiest formats to misuse on the web. A PNG file can be perfect in the design tool and still be the reason your page ships several unnecessary megabytes.
**TL;DR:** Use [Bunny Optimizer](https://try.sunnysah.com/BunnyCDN) when you want the cheapest straightforward PNG delivery layer: $9.50/month per website for Optimizer, plus CDN bandwidth. Use ImageKit when you need a cleaner transformation API, AVIF/WebP format control, lossless mode, uploads, and developer tooling. Use Cloudflare Images if your site already sits behind Cloudflare and your PNG workload maps cleanly to unique transformations. Use Cloudinary only when PNG optimization is part of a larger media workflow, not because it is the cheapest way to serve transparent logos.
Use this short version before going deeper:
| PNG Workload | Best Fit | Why |
| | --- |
| Logos, icons, and screenshots on a normal website | **Bunny Optimizer** | Low fixed optimizer cost, WebP delivery, resize/crop, and simple CDN economics |
| Developer app with uploads and transformation URLs | **ImageKit** | Clean API, `f-auto`, `lo-true`, storage, SDKs, and AVIF/WebP controls |
| Cloudflare-fronted site or Worker/R2 stack | **Cloudflare Images** | Good fit for transformation pricing and Cloudflare routing |
| Editorial, marketplace, or brand media workflow | **Cloudinary** | Advanced transformations, asset management, and AI/media features |
| Tiny static site with a few hand-made assets | **No CDN required** | Pre-export SVG/WebP/AVIF and keep the system simple |
Do not pick a PNG CDN only by looking at compression percentage. The better question is operational:
- Where do the PNG files live?
- Do you need to preserve alpha transparency?
- Do editors upload screenshots?
- Do users upload PNGs?
- Do you need dynamic resizing?
- Do you need WebP only, or AVIF too?
- Do you need transformations in code?
- Is the PNG workload large enough to justify another provider?
For most small sites, a good image CDN is useful because people upload the wrong image sizes. The CDN becomes a guardrail.
PNG is a lossless raster format. It keeps sharp edges, text, flat colors, alpha transparency, and UI details clean. That makes it a good source format for:
Canonical source: [https://theimagecdn.com/docs/image-cdns-for-png](https://theimagecdn.com/docs/image-cdns-for-png) — Markdown: [https://theimagecdn.com/docs/image-cdns-for-png.md](https://theimagecdn.com/docs/image-cdns-for-png.md)
---
## Image CDNs for Startups: $0-15/Month Plans That Scale in 2026
Startups do not need enterprise image CDNs. Compare Cloudflare Images, ImageKit, BunnyCDN, Gumlet, Gcore, and paid media platforms by current pricing, free-plan cliffs, and startup growth stage.
Most startups do not need an enterprise image CDN. They need compressed images, responsive sizes, a clean custom hostname, and a bill that does not become a founder Slack emergency. In 2026, that usually means starting free with Cloudflare Images, ImageKit, or Gumlet, then moving to [BunnyCDN](https://try.sunnysah.com/BunnyCDN) once the site has revenue or predictable traffic.
**TL;DR:** Use free tiers while validating the product. Cloudflare Images gives **5,000 unique transformations/month**, but new transformations over that Free limit return **9422** errors. ImageKit Free gives **20 GB bandwidth** and **3 GB DAM storage**, but delivery stops when limits are hit. Gumlet lists a Free image plan with **30 GB/month**. Once the startup has revenue, BunnyCDN is the safer paid default: **$9.50/month** for Optimizer plus CDN delivery starting at **$0.01/GB** in North America and Europe. Use code **THEWPX** for $5 credit.
For most startups, the answer is:
| Stage | Reasonable image CDN budget | Best fit |
| | --- |
| Landing page / MVP | $0 | Cloudflare Images, ImageKit Free, Gumlet Free |
| Early product | $0-10 | Free tier until limits are close, then BunnyCDN |
| Revenue stage | $10-15 | BunnyCDN + Optimizer |
| Developer-heavy app | $9-25 | ImageKit Lite or Imgix Starter if APIs matter |
| Upload-heavy platform | $66+ | Uploadcare or a custom upload stack |
| Enterprise media workflow | $99+ | Cloudinary or Imgix |
The main thing a startup buys with an image CDN is not "enterprise media infrastructure." It buys three practical outcomes:
- Smaller image files
- Correctly sized responsive variants
- Faster delivery from edge locations
That is enough for most early websites and apps. If the homepage is slow because it serves a 2 MB JPEG hero image, Cloudinary's DAM features are not the fix. The fix is resizing, compression, WebP/AVIF where appropriate, and caching.
The reason this matters early is simple: page weight and mobile speed still affect real users. HTTP Archive's [2025 page weight report](https://almanac.httparchive.org/en/2025/page-weight) shows how much page weight images can add, and its [performance report](https://almanac.httparchive.org/en/2…
Canonical source: [https://theimagecdn.com/docs/image-cdns-for-startups](https://theimagecdn.com/docs/image-cdns-for-startups) — Markdown: [https://theimagecdn.com/docs/image-cdns-for-startups.md](https://theimagecdn.com/docs/image-cdns-for-startups.md)
---
## Best Image CDN for Small Ecommerce Websites in 2026: Product Images, Cost, and Speed
A practical image CDN guide for small ecommerce websites: BunnyCDN, ImageKit, Cloudinary, Cloudflare, Shopify, WooCommerce, product image SEO, cost math, and speed tradeoffs.
The best image CDN for a small ecommerce website is usually **BunnyCDN** if you want cheap product image delivery, **ImageKit** if you need developer-friendly transformations and media storage, and **Cloudinary** if product media management has become an operations problem. Shopify stores should usually start with Shopify's built-in CDN before adding another layer.
**TL;DR:** Use BunnyCDN for most WooCommerce and small ecommerce sites because the bill is predictable and the setup is simple. Use ImageKit when your store is custom-built or needs image APIs, uploads, DAM storage, WebP, AVIF, and clean transformation URLs. Use Cloudinary when the store has serious media workflows: many teams, videos, approvals, product asset libraries, and complex transformations.
If you want the broader provider list, use the [best image CDNs guide](/docs/best-image-cdns). If you only care about monthly cost, use the [paid image CDN pricing comparison](/docs/paid-cdn-options).
Short answer: **BunnyCDN for most stores, ImageKit for custom apps, Cloudinary for media teams.**
| Store Type | Best Image CDN | Why |
| | --- |
| Small WooCommerce store | **BunnyCDN** | Cheap delivery, simple setup, good enough image optimization |
| Shopify store on a normal theme | **Shopify CDN first** | Shopify already optimizes storefront images through its CDN |
| Custom ecommerce app | **ImageKit** | Better URL transformations, uploads, and developer workflow |
| Marketplace with user uploads | **ImageKit or Cloudinary** | Storage, upload APIs, and media management matter |
| Fashion, furniture, beauty, or visual-heavy store | **Cloudinary or ImageKit** | Cropping, variants, visual asset workflow, and video may matter |
| Store with simple product photos and low budget | **BunnyCDN** | Lowest practical cost for image delivery |
This is not only a speed decision.
It is also a workflow decision.
A small store usually needs fast product images. A larger store needs media operations. Those are different problems.
Canonical source: [https://theimagecdn.com/docs/image-cdn-for-ecommerce](https://theimagecdn.com/docs/image-cdn-for-ecommerce) — Markdown: [https://theimagecdn.com/docs/image-cdn-for-ecommerce.md](https://theimagecdn.com/docs/image-cdn-for-ecommerce.md)
---
## Do Image CDNs Improve LCP? Test Setup, Results, and Fixes
Do image CDNs actually improve Largest Contentful Paint? Here is the technical test setup, what changed, what did not, and the exact LCP problems BunnyCDN, ImageKit, and Cloudflare Images can fix.
Short answer: **yes, image CDNs can improve LCP.**
But only when your LCP problem is the image itself.
If the LCP image is too large, too far from the user, served as JPEG/PNG when WebP or AVIF would be smaller, or missing responsive sizes, an image CDN can move the number meaningfully.
If the LCP image is lazy-loaded, hidden behind JavaScript, used as a CSS background, discovered late, blocked by render-heavy scripts, or delayed by slow HTML TTFB, a CDN alone will not fix it.
**TL;DR:** An image CDN improves LCP by reducing **resource load duration**: fewer bytes, better format, closer edge, responsive dimensions. It does not fix **resource load delay** or **render delay** unless you also make the LCP image discoverable in HTML, preload it when needed, and set `fetchpriority="high"`.
LCP measures when the largest visible image or text block in the viewport finishes rendering.
Google's good threshold is **2.5 seconds or less** for at least 75% of page visits, according to the [web.dev LCP optimization guide](https://web.dev/articles/optimize-lcp).
For image-heavy pages, the LCP element is often:
Canonical source: [https://theimagecdn.com/docs/do-image-cdns-improve-lcp](https://theimagecdn.com/docs/do-image-cdns-improve-lcp) — Markdown: [https://theimagecdn.com/docs/do-image-cdns-improve-lcp.md](https://theimagecdn.com/docs/do-image-cdns-improve-lcp.md)
---
## Best Free Image CDN in 2026: Real Limits, Failure Modes & Upgrade Paths
ImageKit, Cloudflare Images, Cloudinary, Uploadcare, Sirv, Gcore Image Stack, and jsDelivr compared by real free limits, format support, storage, bandwidth, operations, and what breaks first.
Short answer: **ImageKit is still the best free image CDN for most normal websites in 2026.**
It has the cleanest free balance: **20 GB monthly bandwidth**, **3 GB DAM storage**, standard image transformations, a real CDN, and a simple upgrade path at $9/month.
But the honest answer is not "use ImageKit for everything."
Use **Cloudflare Images** if your site already sits behind Cloudflare and you can stay under 5,000 unique monthly transformations. Use **Cloudinary** if you are building a media-heavy prototype. Use **Uploadcare** if users upload files. Use **Sirv** for product zoom and 360 spins. Use **jsDelivr** only for public static images that you already optimized yourself.
**TL;DR:** Free image CDNs are useful, but every free plan has a first wall. ImageKit usually hits bandwidth or storage first. Cloudflare hits unique transformations. Cloudinary burns credits. Uploadcare burns operations. Sirv hits storage or transfer. jsDelivr has no optimizer. Pick by the limit you can live with.
> Looking at paid options too? The [paid image CDN pricing guide](/docs/paid-cdn-options) covers the upgrade path once free tiers become too fragile.
A free CDN and a free image CDN are not the same product.
A **free CDN** caches and serves the file you already created. If your origin has a 2 MB JPEG, the CDN can serve that same 2 MB JPEG from a nearby edge location.
Canonical source: [https://theimagecdn.com/docs/free-image-cdns](https://theimagecdn.com/docs/free-image-cdns) — Markdown: [https://theimagecdn.com/docs/free-image-cdns.md](https://theimagecdn.com/docs/free-image-cdns.md)
---
## Cloudinary Pricing Explained (2026): Credits, Free Tier & What You Actually Pay
Cloudinary pricing runs on credits: 1 credit = 1,000 transformations, 1 GB storage, or 1 GB bandwidth. Free gives 25 credits, Plus is $89/mo, Advanced $224/mo — and fixed tiers suspend instead of billing overages.
Cloudinary pricing confuses people for one reason: you do not pay for transformations, storage, and bandwidth separately. You pay for all three out of a single bucket called credits.
**Short answer:** One Cloudinary credit covers **1,000 transformations, 1 GB of managed storage, or 1 GB of delivered bandwidth** — any mix of the three. The **Free** plan gives you **25 credits/month**. **Plus** is **$89/month** (billed yearly) for **225 credits**, and **Advanced** is **$224/month** for **600 credits**. The catch most reviews skip: Free, Plus, and Advanced do not bill overages at all — they warn you, and eventually disable the account instead.
[Cloudinary](https://cloudinary.com/) does not sell you a fixed amount of storage or a fixed number of image requests. It sells you credits, and you spend them on whatever your site actually uses that month.
That is the whole model. Transformations, storage, and bandwidth all draw from the same monthly credit balance.
| Plan | Yearly price | Monthly price | Monthly credits | Users / accounts |
| | --- | --- | --- |
| **Free** | $0 | $0 | 25 | 3 / 1 |
| **Plus** | $89/mo | $99/mo | 225 | 3 / 2 |
| **Advanced** | $224/mo | $249/mo | 600 | 5 / 3 |
| **Enterprise** | Custom | Custom | Custom | SSO, multi-CDN |
The flexibility sounds great, and for small sites it genuinely is. The problem is predictability. Because three different meters share one balance, you cannot look at a plan and instantly know if it fits — you have to convert your real usage into credits first.
That is what the next section does.
A credit is the single unit Cloudinary uses for everything. According to [Cloudinary's own documentation](https://cloudinary.com/documentation/developer_onboarding_faq_credits), one credit is interchangeable across three meters.
Canonical source: [https://theimagecdn.com/docs/cloudinary-pricing](https://theimagecdn.com/docs/cloudinary-pricing) — Markdown: [https://theimagecdn.com/docs/cloudinary-pricing.md](https://theimagecdn.com/docs/cloudinary-pricing.md)
---
## BunnyCDN Pricing Explained (2026): What You Actually Pay for CDN + Optimizer
BunnyCDN pricing is pay-as-you-go: CDN bandwidth from $0.01/GB, a $1 monthly minimum, and Bunny Optimizer at a flat $9.50/zone. Here is the real per-site cost, the regional catch, and how it compares to Cloudinary and Cloudflare Images.
BunnyCDN pricing is pay-as-you-go, and that is the whole story: CDN bandwidth from **$0.01/GB**, a **$1 monthly minimum**, and the [Bunny Optimizer](https://bunny.net/optimizer/) as a flat **$9.50/month per Pull Zone** if you want image optimization on top. No plans, no seats, no contract.
**TL;DR:** For plain CDN delivery, most small sites pay the **$1/month minimum** — bandwidth at $0.01/GB in Europe and North America rarely adds up to more. Turn on Bunny Optimizer for WebP, resizing, and minification and you add a flat **$9.50/month per zone**, so a real image-CDN setup lands near **$10–12/month** with no overage surprises.
You pay for what you use, billed mostly on bandwidth.
There are no monthly plans to choose. Instead, BunnyCDN charges for the gigabytes you deliver, the storage you keep, and a small number of flat add-ons like Optimizer. Every core CDN feature — free TLS, HTTP/3, Perma-Cache, origin shield, real-time analytics — is included with no upsell tier.
That is the part people miss when they compare BunnyCDN to credit or seat-based tools. There is no "Pro plan." The bill is built from usage, with a **$1 monthly minimum** so a near-idle account still costs a dollar.
This makes BunnyCDN behave like a [traditional pay-as-you-go CDN](/docs/image-cdn-vs-traditional-cdn) rather than a packaged image platform. The trade-off is simple: you get the lowest predictable cost, but you assemble the pieces yourself — CDN, then Storage, then Optimizer.
Bandwidth is region-based, and Europe and North America are the cheapest.
BunnyCDN runs two networks. The **Standard Network** (119 PoPs) is the default — fast everywhere, priced per region. The **Volume Network** (10 PoPs) is a cheaper flat-rate option for huge transfer volumes where you do not need every edge location.
Canonical source: [https://theimagecdn.com/docs/bunnycdn-pricing](https://theimagecdn.com/docs/bunnycdn-pricing) — Markdown: [https://theimagecdn.com/docs/bunnycdn-pricing.md](https://theimagecdn.com/docs/bunnycdn-pricing.md)
---
## Can Image CDNs Convert Image Formats? Yes - Here Is How
Image CDNs can convert JPEG, PNG, WebP, and AVIF at request time. Learn how auto format works, which providers support it, and what can go wrong.
Yes. Image CDNs can convert image formats automatically. You can upload a JPEG or PNG source and serve WebP, AVIF, JPEG, PNG, or the original format depending on browser support, URL parameters, and provider settings. The important part is not whether conversion is possible. It is whether your CDN does it predictably, caches the right variants, and preserves the image features you care about.
**TL;DR:** Image CDNs convert formats by reading the browser's `Accept` header, generating the best supported derivative, and caching that derivative at the edge. WebP is the safest modern default. AVIF can be smaller, but support and encode speed vary by provider. PNG transparency is preserved when converting to WebP or AVIF, but lost if you force JPEG. Use `format=auto`, `f-auto`, or the provider's automatic format mode where possible, and keep fallback behavior explicit.
When a browser requests an image, it sends an `Accept` header. That header tells the server which image formats the browser can decode.
```http
Accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
```
An image CDN reads that header and decides what to serve.
The same source URL can return different response formats:
```html
```
```http
Content-Type: image/avif
```
Canonical source: [https://theimagecdn.com/docs/can-image-cdn-convert-formats](https://theimagecdn.com/docs/can-image-cdn-convert-formats) — Markdown: [https://theimagecdn.com/docs/can-image-cdn-convert-formats.md](https://theimagecdn.com/docs/can-image-cdn-convert-formats.md)
---
## Best Image CDN in 2026: 9 Providers Compared by Pricing, Features, and Use Case
BunnyCDN, ImageKit, Cloudflare Images, Gcore, Cloudinary, Imgix, Sirv, Gumlet, and Uploadcare compared by current pricing, billing model, WebP/AVIF support, free-plan limits, and real monthly cost.
The best image CDN for most websites in 2026 is **BunnyCDN** because the bill stays boring: low per-GB delivery plus a flat **$9.50/month** Optimizer. **ImageKit** is the better developer pick when you want upload APIs, URL transformations, DAM storage, and bandwidth-based pricing. **Cloudflare Images** is excellent for small Cloudflare-native sites, but its Free plan has a hard **5,000 unique transformation** ceiling and new variants over that limit return a **9422** error.
**TL;DR:** Start with [BunnyCDN](https://try.sunnysah.com/BunnyCDN) if you run a blog, agency site, documentation site, affiliate site, or normal ecommerce store. Use code **THEWPX** for $5 free credit. Test ImageKit if the project needs developer APIs, uploads, media library features, or no per-transform meter. Use Cloudflare Images when your image count is small or the site already lives deeply inside Cloudflare. Use Cloudinary, Uploadcare, or Imgix only when you need the platform features, not just faster JPEGs.
**Jump to:** [Ranking table](#best-image-cdns-ranked) · [Billing models](#image-cdn-billing-models-matter-more-than-feature-lists) · [BunnyCDN](#1-bunnycdn-best-overall-value) · [ImageKit](#2-imagekit-best-for-developer-teams) · [Cloudflare Images](#3-cloudflare-images-best-for-small-cloudflare-native-sites) · [Gcore](#4-gcore-image-stack-best-for-global-avif-testing) · [Cloudinary](#5-cloudinary-best-for-enterprise-media-workflows) · [Other providers](#other-image-cdns-worth-considering) · [Format support](#format-support-webp-avif-and-jpeg-xl) · [Cost comparison](#cost-comparison-at-real-traffic-levels) · [FAQ](#frequently-asked-questions)
> **Last updated:** 18 June 2026. Pricing and limits were checked against provider pricing pages and docs on that date.
Not sure you even need a separate image CDN? Read the [do I need a CDN decision guide](/docs/do-i-need-cdn). Already know you want a free option first? Use the [free image CDNs comparison](/docs/free-image-cdns).
| Rank | Provider | Best for | Typical monthly cost | Main catch |
| | --- | --- | --- |
| 1 | **BunnyCDN** | Most websites that want predictable image optimization | $10-15 | WebP yes, AVIF no |
| 2 | **Image…
Canonical source: [https://theimagecdn.com/docs/best-image-cdns](https://theimagecdn.com/docs/best-image-cdns) — Markdown: [https://theimagecdn.com/docs/best-image-cdns.md](https://theimagecdn.com/docs/best-image-cdns.md)
---
## ImageKit Pricing: Free, Lite and Pro Plan Limits Compared
ImageKit free gives 20 GB bandwidth, 3 GB DAM storage, and 2 users. Lite starts at $9/month with 40 GB and pay-as-you-go overage. Every plan limit compared, and what breaks first.
Short answer: ImageKit has three self-serve plans — **Free** at $0 with 20 GB bandwidth, **Lite** at $9/month with 40 GB, and **Pro** at $89/month with 225 GB. Free is good for small sites, tests, and portfolios, but it stops delivering images at the cap. Lite is the first plan that bills overage instead of breaking.
On Free you get 20 GB of monthly bandwidth, 3 GB of DAM storage, 2 users, 500 purge requests, 500 video units, and 650 extension units. Image transformations and optimization are included, which is the useful part.
The two limits that matter most are bandwidth and storage.
Bandwidth resets every month. Storage does not.
Here is the current free-plan limit table for ImageKit's complete media processing and DAM product.
| Limit | Free plan | Resets? | What happens at the limit |
| : | --- | --- |
| Bandwidth | 20 GB/month | Yes | Media delivery stops until reset |
| DAM storage | 3 GB | No | New file uploads stop |
| Users | 2 | No | You cannot add more users |
| Purge requests | 500/month | Yes | New cache purge requests stop |
| Video units | 500/month | Yes | New video processing stops |
| Extension units | 650/month | Yes | AI extensions stop |
| Custom domains | 0 included | No | You use ImageKit's default URL |
| External origins | 2 | No | You cannot add more origins |
| URL endpoints | 2 | No | You cannot add more endpoints |
| Image upload size | 25 MB | Per file | Larger uploads are blocked |
| Output image resolution | 25 MP | Per output | Larger outputs are blocked |
Source: ImageKit's public pricing page.
The headline numbers are simple. The behavior behind them is what decides whether the plan fits your site.
Canonical source: [https://theimagecdn.com/docs/free-image-cdns/imagekit-free-plan-limits](https://theimagecdn.com/docs/free-image-cdns/imagekit-free-plan-limits) — Markdown: [https://theimagecdn.com/docs/free-image-cdns/imagekit-free-plan-limits.md](https://theimagecdn.com/docs/free-image-cdns/imagekit-free-plan-limits.md)
---
## ImageKit Coupon Code 2026 — The Real Discounts (No Fake Codes)
There is no ImageKit coupon code you paste at checkout. Here are the real ways to pay less on ImageKit in 2026 — the free plan, Startup Program, prepay discount, and nonprofit discount — plus the honest catch.
There is no ImageKit coupon code you can paste at checkout. The "40% off" and "55% off" codes on coupon-aggregator sites do not map to any field in ImageKit's billing. What ImageKit actually gives you is a free plan, a Startup Program, a prepay discount, and a nonprofit discount — real savings, just not a promo box.
**TL;DR:** ImageKit has no public coupon or promo code. The genuine discounts in 2026 are the Forever Free plan (20 GB bandwidth, 3 GB storage), the Startup Program (usage-based pricing from $0.10/GB, for eligible funded startups), a 15% discount when you prepay $500–$5,000, and a 25% nonprofit discount. If you specifically want a code and free credit, [BunnyCDN](/docs/bunnycdn-coupon) is the provider that gives one.
No. Not in the way most people mean it.
ImageKit's billing has no promo code field where you type something like `SAVE40` and watch the price drop. I checked the pricing page and the signup flow, and there is no coupon box for a public discount code.
The coupon sites ranking for "ImageKit coupon code" — couponwcode, tenereteam, oodiscount and similar — list codes like "40% off" or "75% off AI transformations." These are scraped or invented listings. They do not correspond to a real ImageKit checkout mechanism, and most link back to the normal signup page.
So treat any "working ImageKit promo code" claim with suspicion. If a page shows a code but never shows the billing screen where it applied, assume it does not work.
The good news: ImageKit does have real ways to pay less. They are just programs, not codes.
There are four, and each has a clear condition.
Canonical source: [https://theimagecdn.com/docs/imagekit-coupon-code](https://theimagecdn.com/docs/imagekit-coupon-code) — Markdown: [https://theimagecdn.com/docs/imagekit-coupon-code.md](https://theimagecdn.com/docs/imagekit-coupon-code.md)
---
## How to Migrate Images to a CDN Without Losing SEO
A safe, five-phase plan to move your existing images to a CDN without breaking links, dropping out of Google Images, or losing ranking signals. Includes the one-to-one 301 rule and the redirect-loop trap most guides miss.
Moving images to a CDN is one of the highest-value performance changes you can make. It is also the one people put off, because the fear is real: change every image URL on the site and something is going to break.
That fear is fixable. Broken image SEO after a migration is almost always caused by two mistakes — dropping old URLs with no redirect, or redirecting them badly. Avoid both and the move is boring, which is exactly what you want.
**TL;DR:** Whether you need redirects depends on *how* the CDN serves your images. If the CDN fronts your origin under a new hostname, old URLs keep working and you just rewrite references. If you move files to new storage, add a **one-to-one 301** from each old image URL to its exact new CDN URL — never to the homepage, never through a chain. Then verify in Search Console.
Not by itself. Changing an image URL only hurts SEO when the old URL stops resolving and you leave nothing in its place.
Images accumulate real search equity over time. They rank in [Google Images](/docs/can-image-cdns-hurt-seo), they get hotlinked and embedded, and they sit inside pages that rank. When an old image URL suddenly 404s, all of that is at risk — the image drops from Google Images, embeds show a broken box, and the page loses a signal.
Google's own guidance is that a **301 permanent redirect** tells Search a URL has moved and passes its signals to the new location, per the [Redirects and Google Search documentation](https://developers.google.com/search/docs/crawling-indexing/301-redirects). So the migration is safe as long as every old URL either keeps working or points cleanly to its replacement.
The mistake is not "changing the URL." The mistake is changing it and forgetting the old one existed.
This is the part most guides skip, and getting it wrong causes an actual outage. There are two migration modes, and only one of them needs redirects.
Canonical source: [https://theimagecdn.com/docs/migrate-images-to-cdn](https://theimagecdn.com/docs/migrate-images-to-cdn) — Markdown: [https://theimagecdn.com/docs/migrate-images-to-cdn.md](https://theimagecdn.com/docs/migrate-images-to-cdn.md)
---
## Beyond LCP: How Images Cause CLS and Hurt INP
LCP is only one of three Core Web Vitals images touch. Here is exactly how images trigger Cumulative Layout Shift, where they drag Interaction to Next Paint, and the markup and CDN settings that fix both.
Most image performance advice stops at LCP. That leaves two-thirds of Core Web Vitals unattended.
Images do not only decide how fast your hero paints. They also decide whether your layout jumps while people read, and they can quietly add to the delay between a tap and a response.
If you have already optimised [Largest Contentful Paint](/docs/do-image-cdns-improve-lcp) and your field data still shows red, an image is often the reason — just not the way you expected.
**TL;DR:** Images cause **Cumulative Layout Shift (CLS)** when they load without reserved space, pushing content down. They add to **Interaction to Next Paint (INP)** when a huge file decodes on the main thread and blocks the frame that answers a tap. Fix CLS with `width`/`height` or `aspect-ratio`. Fix the image side of INP with smaller, modern files — which is exactly what a CDN delivers.
Core Web Vitals is three metrics, and images touch all three.
- **LCP** measures loading — often a hero or product image.
- **CLS** measures visual stability — how much the page jumps while it loads.
- **INP** measures responsiveness — the delay from an interaction to the next painted frame.
LCP gets all the attention because it is the easiest to explain and the easiest for a CDN to move. But a page can have a fast LCP and still fail the assessment because content jumps around (CLS) or taps feel sluggish (INP).
Google assesses each metric at the **75th percentile** of real visits. So one metric in the red is enough to mark the URL as "needs improvement." Fixing LCP alone does not get you a passing grade.
Canonical source: [https://theimagecdn.com/docs/how-images-affect-cls-and-inp](https://theimagecdn.com/docs/how-images-affect-cls-and-inp) — Markdown: [https://theimagecdn.com/docs/how-images-affect-cls-and-inp.md](https://theimagecdn.com/docs/how-images-affect-cls-and-inp.md)
---
## Why Your Website Needs an Image CDN
Images are usually the largest payload on a webpage and often control LCP. This technical breakdown explains when an image CDN helps, what it fixes, and what it does not fix.
Your pages feel slow, the usual culprit is the images, and everyone keeps telling you an image CDN will fix it. But why does moving images to a CDN do more than a regular CDN — or no CDN at all?
A normal CDN moves files closer to visitors.
An image CDN does that, then also makes the files smaller.
It can resize a 3000px source photo to the 900px version the page actually needs. It can serve AVIF or WebP instead of JPEG. It can cache the optimized result at the edge.
That is the core reason it works.
Not magic. Fewer bytes, better formats, less origin work, lower latency.
The [HTTP Archive 2025 Web Almanac](https://almanac.httparchive.org/en/2025/page-weight) reports that the median desktop home page transfers about **1,058 KB of images**. Median mobile home pages transfer about **911 KB of images**.
On many marketing sites, blogs, real estate sites, directories, restaurants, SaaS pages, and e-commerce stores, images are the largest payload before you even look at JavaScript.
Canonical source: [https://theimagecdn.com/docs/why-your-website-needs-image-cdn](https://theimagecdn.com/docs/why-your-website-needs-image-cdn) — Markdown: [https://theimagecdn.com/docs/why-your-website-needs-image-cdn.md](https://theimagecdn.com/docs/why-your-website-needs-image-cdn.md)
---
## Smart Cropping with Image CDNs - How Auto Crop Actually Works
Smart cropping uses face detection, subject detection, saliency, gravity, and focus points to crop images without cutting off important content. Learn when to use it and when to override it.
You crop one product photo into a square thumbnail and the model's head gets sliced off. Do that across hundreds of images and a handful of aspect ratios, and cropping each one by hand stops being realistic.
That is the problem smart cropping solves. It is automatic image cropping that keeps the important part of the image in frame — instead of blindly cropping from the center, an image CDN uses face detection, subject detection, saliency, gravity, or a manual focus point to decide what stays visible.
**TL;DR:** Use smart cropping for avatars, product thumbnails, cards, social previews, and responsive layouts where one source image needs many aspect ratios. Use **face detection** for people, **automatic gravity/saliency** for mixed editorial images, **manual gravity** when the subject position is predictable, and **focus points** when accuracy matters. Do not trust smart cropping blindly for hero images, important product shots, legal/medical content, or user-generated content where a bad crop can create bias or confusion.
Use smart cropping when the same image has to fit multiple boxes.
| Use case | Smart crop? | Best method |
| | --- |
| User avatars | Yes | Face detection |
| Author cards | Yes | Face detection or saved focus point |
| Product grids | Usually | Focus point or gravity |
| Blog cards | Yes | Auto gravity/saliency |
| Social preview images | Yes, with QA | Auto crop or focus point |
| Hero images | Be careful | Manual crop or pre-warmed smart crop |
| Legal, medical, safety images | Be careful | Manual review |
| Brand logos | Usually no | SVG, contain, or manual padding |
Smart cropping is not magic. It is a practical way to avoid manually exporting 10 versions of every image.
The best use case is a repeatable template: square avatar, 4:3 card image, 16:9 blog thumbnail, 1:1 product grid, 9:16 story crop. If the crop is wrong, the layout still works but the image may look less useful. That is acceptable for low-risk variants.
For high-value images, I still prefer a manual crop or a saved focus point.
Canonical source: [https://theimagecdn.com/docs/smart-cropping](https://theimagecdn.com/docs/smart-cropping) — Markdown: [https://theimagecdn.com/docs/smart-cropping.md](https://theimagecdn.com/docs/smart-cropping.md)
---
## Image CDN vs Traditional CDN: What Actually Changes
A technical comparison of image CDNs and traditional CDNs: caching, resizing, format conversion, compression, asset coverage, pricing, and when to use each.
You already know a CDN makes your site faster. Then someone mentions an "image CDN," and now you are not sure if it is the same thing, a different thing, or something you are meant to run on top of the one you have.
```txt
2 MB JPEG -> 2 MB JPEG from a nearby edge
```
```txt
2 MB JPEG -> resized WebP/AVIF variant from a nearby edge
```
Use a traditional CDN when your assets are already optimized and you mainly need global caching.
Use an image CDN when your images need resizing, compression, format conversion, or transformation.
For many real sites, the best setup is both: a general CDN for CSS/JS/fonts/downloads and an image CDN pipeline for images. BunnyCDN with [Optimizer](https://bunny.net/optimizer/) and Cloudflare with image transformations are hybrid examples.
A traditional CDN is a distributed cache for files.
It stores copies of your assets on edge servers and serves those copies from a location closer to the visitor.
Canonical source: [https://theimagecdn.com/docs/image-cdn-vs-traditional-cdn](https://theimagecdn.com/docs/image-cdn-vs-traditional-cdn) — Markdown: [https://theimagecdn.com/docs/image-cdn-vs-traditional-cdn.md](https://theimagecdn.com/docs/image-cdn-vs-traditional-cdn.md)
---
## Do I Need a CDN? A Practical Decision Framework
A simple technical framework for deciding whether your website needs a CDN, an image CDN, or no CDN yet.
Every speed-test tool eventually nags you to "use a CDN," and every host has one to upsell. So do you actually need it — or is it a fix for a problem you do not have yet?
But you may not need one today.
That is the important distinction.
A CDN is useful when it solves a real bottleneck:
- your files are far from visitors
- your image payload is too large
- your origin is serving too many static requests
- your LCP image loads slowly
- your hosting struggles during traffic spikes
If your site is a small local text site with fast hosting and almost no images, a CDN is optional.
For most visual websites, especially blogs, portfolios, SaaS pages, directories, and e-commerce stores, a CDN is worth testing.
| Question | If yes | What it means |
| | --- |
| Do visitors come from more than one region? | Use a CDN | Edge delivery will reduce network latency |
| Are images a large part of the page? | Use an image CDN | You need resizing, compression, and WebP/AVIF |
| Is LCP slow because of a hero image? | Test an image CDN | It may reduce image load duration |
| Does your origin serve lots of static files? | Use a CDN | It reduces server bandwidth and request load |
| Are you already on Vercel, Netlify, Cloudflare Pages, or similar? | Maybe skip basic CDN | You may already have edge delivery |
Canonical source: [https://theimagecdn.com/docs/do-i-need-cdn](https://theimagecdn.com/docs/do-i-need-cdn) — Markdown: [https://theimagecdn.com/docs/do-i-need-cdn.md](https://theimagecdn.com/docs/do-i-need-cdn.md)
---
## Best WordPress Image Optimization Plugins in 2026: Compression, WebP/AVIF & Pricing Compared
A practical comparison of the best WordPress image optimization plugins — Smush, ShortPixel, Imagify, EWWW, Optimole, and Converter for Media — on compression, WebP/AVIF support, free tiers, and price. Which to install, and which to skip.
You add a few images to a post, your PageSpeed score drops, and the advice is always the same: "just install an image optimization plugin." Then you open WordPress.org, search for one, and find over 2,400 of them — all promising the exact same thing. Sound familiar?
Here's the catch nobody mentions: these plugins are not interchangeable. The free tiers count completely different things — images, megabytes, visits, or nothing at all. Some only convert to WebP. A couple are really image CDNs wearing a plugin's clothes.
So this isn't another "top 10" list where every pick magically wins. It's the honest sort — which plugin to actually install, which to skip, and when you're better off not using a plugin at all.
Images are the heaviest thing on most pages. According to the [HTTP Archive Web Almanac](https://almanac.httparchive.org/en/2024/page-weight), images make up roughly 40% of the median desktop homepage by weight — 1,054 KB out of 2,652 KB. On a typical WordPress site, that weight comes from editors uploading full-size camera and phone photos straight into the media library.
Optimization attacks that weight in three ways: it compresses the file, it serves a modern format like WebP or AVIF, and it sizes the image to the space it actually fills. Google's [web.dev guidance](https://web.dev/learn/performance/image-performance) notes AVIF can cut image bytes by more than 50% versus JPEG in some cases.
That is why the right plugin is one of the quickest wins for Largest Contentful Paint. If your hero image is a 600 KB JPEG, converting and compressing it does more for [LCP](/docs/do-image-cdns-improve-lcp) than most other speed tweaks combined.
Here is the honest snapshot. Prices and limits are current as of June 2026, taken from each vendor's own pages.
| Plugin | Active installs | Free tier | Entry paid price | WebP | AVIF | Built-in CDN |
| : | --- | ---: | :---: | :---: | :---: |
| **ShortPixel** | 300,000+ | 100 credits/mo | $9.99/mo (Unlimited) | Yes | Yes (local) | No |
| **Smush** | 1,000,000+ | Unlimited local, no quota | $36/yr (Pro, 1 site) | Yes | Yes (Pro) | Yes (Pro) |
| **Imagify** | 1,000,000+ | 20 MB/mo (~200 images) | $4.99/mo yearly | Yes |…
Canonical source: [https://theimagecdn.com/docs/best-wordpress-image-optimization-plugins](https://theimagecdn.com/docs/best-wordpress-image-optimization-plugins) — Markdown: [https://theimagecdn.com/docs/best-wordpress-image-optimization-plugins.md](https://theimagecdn.com/docs/best-wordpress-image-optimization-plugins.md)
---
## Is PNG Lossy or Lossless? The Direct Answer
PNG is a lossless image format. Learn how PNG compression works, why PNG files can still be optimized, and when tools like TinyPNG or pngquant make PNG workflows lossy.
PNG is lossless. A normal PNG file preserves every pixel exactly. You can decode it, edit it, and save it again without JPEG-style generation loss. The confusion comes from tools that create smaller PNG files by reducing colors first. The PNG format is lossless; some PNG optimization workflows are not.
**TL;DR:** **PNG is a lossless image format.** Its compression is reversible and does not throw away image data. Use PNG for screenshots, UI images, diagrams, transparent graphics, and raster logos when exact pixels matter. The exception is not the PNG format itself. It is tools like TinyPNG, pngquant, or PNG-8 export settings that reduce colors before saving. Those workflows can be lossy even though the output file is still `.png`.
The [W3C PNG Third Edition specification](https://www.w3.org/TR/png-3/) describes PNG as a lossless, portable, well-compressed format for static and animated raster images. That means the format is built to store pixel data without discarding it.
If you save a clean screenshot as PNG, the text and UI edges remain exact. If you open that PNG and save it again as PNG, it does not degrade the way JPEG does.
| Situation | Is quality lost? | Why |
| | --- |
| Save image as normal PNG | No | PNG compression is reversible |
| Re-save PNG as PNG | No, if pixels are unchanged | No generation loss |
| Compress PNG with OptiPNG/oxipng | No | Recompresses same pixels |
| Convert JPEG to PNG | Quality is not restored | JPEG damage already exists |
| Use TinyPNG/pngquant aggressively | Yes, often | Colors may be reduced |
| Export PNG-8 from a full-color image | Yes, if colors are reduced | Palette limit changes pixels |
So the clean answer is: PNG is lossless, but a PNG file can contain image data that was already damaged or reduced before it became PNG.
PNG compression has two main ideas: filtering and DEFLATE.
Before compression, PNG can transform each row of pixels with prediction filters. Instead of storing every value directly, the file can store differences from nearby pixels.
Canonical source: [https://theimagecdn.com/docs/is-png-lossy-or-lossless](https://theimagecdn.com/docs/is-png-lossy-or-lossless) — Markdown: [https://theimagecdn.com/docs/is-png-lossy-or-lossless.md](https://theimagecdn.com/docs/is-png-lossy-or-lossless.md)
---
## HEIC vs JPG - Which Should You Use in 2026? (Quality, Size & Compatibility)
A practical HEIC vs JPG comparison: file size, quality, iPhone settings, and browser support. When to keep HEIC, when to switch to JPG, and how to convert without losing quality.
HEIC saves you roughly half the storage. JPG opens everywhere. That is the whole trade-off in one line. Keep HEIC on your iPhone to fit more photos, and convert to JPG the moment you need to share, edit, or publish where HEIC is not supported.
**TL;DR:** Use **HEIC** as your iPhone capture format to halve photo storage with no visible quality loss. Switch to **JPG** when a file has to leave the Apple world, because HEIC still has only [14.12% browser support](https://caniuse.com/heif) and breaks on many Windows, Android, and web tools. For websites, do not serve either one raw. Convert your source to **WebP or AVIF** through an [image CDN](/docs/can-image-cdn-convert-formats) and keep JPG as the universal fallback.
Short answer: keep HEIC for storage, use JPG for sharing and compatibility.
HEIC is the better file. It is smaller, stores richer colour, and holds extras like Live Photos and depth maps. JPG is the more useful file in practice, because almost every device, app, and website on earth can open it without complaint.
| Situation | Best choice | Why |
| | --- |
| Everyday iPhone photos | **HEIC** | Half the file size, same visible quality |
| Sending to an Android user | **JPG** | HEIC often will not open or preview |
| Uploading to old websites or forms | **JPG** | Many uploaders reject HEIC outright |
| Editing in older software | **JPG** | Legacy editors cannot read HEIC |
| Email attachments | **JPG** | Safest format for unknown recipients |
| Archiving your photo library | **HEIC** | Keeps detail at a smaller storage cost |
| Publishing on a website | **WebP or AVIF, JPG fallback** | HEIC is not a web delivery format |
| Printing at a lab | **JPG** | Most print services expect JPG |
If you live inside Apple devices, HEIC is the right default and you rarely have to think about it. The friction starts the moment a file crosses into Windows, Android, or the web.
That is the real decision. Not "which format is technically better," but "where is this photo going next." The format that travels well is JPG.
As of June 2026, this is the practical comparison.
Canonical source: [https://theimagecdn.com/docs/heic-vs-jpg](https://theimagecdn.com/docs/heic-vs-jpg) — Markdown: [https://theimagecdn.com/docs/heic-vs-jpg.md](https://theimagecdn.com/docs/heic-vs-jpg.md)
---
## How to Minimize Cloudflare Images Costs (2026): 7 Practical Levers
Cloudflare Images costs depend on whether you use remote transformations or hosted Images. Use these seven levers to avoid 9422 errors, reduce unique variants, pick the cheaper billing path, and know when BunnyCDN is cheaper.
Cloudflare Images gets expensive when you treat it like one simple product. It is not one simple billing model. Remote images are billed by **unique transformations**. Images stored inside Cloudflare Images are billed by **images stored** and **images delivered**. Free accounts also have a hard transformation limit: after **5,000 unique transformations/month**, new variants return a **9422** error instead of turning into paid overage.
**TL;DR:** First decide whether your site should use remote transformations or hosted Cloudflare Images. Remote transformations are best when traffic is high and the same image variants are reused many times. Hosted Images can be cheaper when delivery volume is modest and you want Cloudflare to store the files. Then reduce the bill by using `format=auto`, limiting responsive sizes, avoiding Workers Images for cacheable variants, cleaning up URL parameters, monitoring the 5,000-transform ceiling, and comparing against flat-rate tools like [BunnyCDN](https://try.sunnysah.com/BunnyCDN).
Cloudflare Images has two practical paths.
| Setup | What you store | What Cloudflare bills |
| | --- |
| Remote transformations | Originals in R2, S3, your server, or another origin | Images Transformed |
| Hosted Cloudflare Images | Originals uploaded into Cloudflare Images | Images Stored + Images Delivered |
This is the detail most cost guides miss.
If you optimize an image stored outside Cloudflare Images, Cloudflare bills **Images Transformed**. Images Paid includes the first **5,000 unique transformations** each month, then charges **$0.50 per 1,000**.
If you upload the image into Cloudflare Images, Cloudflare bills **Images Stored** and **Images Delivered**. Storage is **$5 per 100,000 images/month**. Delivery is **$1 per 100,000 delivered images/month**. Cloudflare's pricing docs also say optimized images stored in Cloudflare Images count toward Images Delivered, not Images Transformed.
That means you need two formulas, not one.
Canonical source: [https://theimagecdn.com/docs/how-to-minimize-cloudflare-images-costs](https://theimagecdn.com/docs/how-to-minimize-cloudflare-images-costs) — Markdown: [https://theimagecdn.com/docs/how-to-minimize-cloudflare-images-costs.md](https://theimagecdn.com/docs/how-to-minimize-cloudflare-images-costs.md)
---
## EWWW Image Optimizer Review - Is It Still Worth Using in 2026?
A practical EWWW Image Optimizer review covering the free plugin, Easy IO CDN, current pricing, WordPress tradeoffs, benchmarks, and better alternatives.
EWWW Image Optimizer is still one of the most useful WordPress image optimization plugins, but only if you understand what problem you are hiring it to solve. The free plugin is excellent for unlimited local optimization and privacy. The paid product is really an image CDN bundle. Those are two different buying decisions.
**TL;DR:** Use EWWW if you want a mature WordPress plugin that can optimize images locally, generate WebP files, bulk-process your Media Library, and keep images on your own server. Upgrade to Easy IO if you want one plugin to handle image optimization, CDN delivery, WebP/AVIF, responsive sizing, and basic performance work. Do not choose EWWW just because the free tier says "unlimited." Free local optimization is useful, but it will not shrink most JPEG-heavy sites enough by itself. If you need the best delivery layer, transformation API, multi-platform support, or clean CDN independence, use a dedicated [image CDN](/docs/best-image-cdns) instead.
EWWW Image Optimizer is worth using in 2026 if your site is WordPress-only and you want the simplest path from "my uploads are too heavy" to "my images are compressed, lazy loaded, converted to modern formats, and served from a CDN."
It is not the strongest standalone image delivery stack. Easy IO is convenient, not especially flexible. It does not replace ImageKit, Cloudinary, Imgix, Bunny Optimizer, or Cloudflare Images if you need an image API, custom transformations, non-WordPress workflows, or predictable control over every URL.
The plugin's biggest advantage is still the free local optimizer. Most WordPress image plugins depend on a cloud account, monthly credits, or an external service. EWWW can optimize files on your own server with no API key. That matters for privacy-sensitive sites, small blogs, intranets, client projects that cannot send uploads to another processor, and anyone who wants a no-account plugin that just runs.
The tradeoff is compression depth. Lossless local compression can clean up metadata and reduce waste, but it will not magically turn a 500 KB JPEG into a 90 KB image. For meaningful savings on photo-heavy pages, you either need EWWW's paid cloud compression, Easy I…
Canonical source: [https://theimagecdn.com/docs/ewww-image-optimizer-review](https://theimagecdn.com/docs/ewww-image-optimizer-review) — Markdown: [https://theimagecdn.com/docs/ewww-image-optimizer-review.md](https://theimagecdn.com/docs/ewww-image-optimizer-review.md)
---
## Cloudflare Images Pricing 2026: Free vs Paid, Remote Images & Real Cost Math
Cloudflare Images pricing depends on how you use it: 5,000 free remote transformations, $0.50/1,000 on Paid, or $5/100K stored images plus $1/100K delivered images for hosted Images.
Cloudflare Images pricing is not one simple meter. The price depends on whether you are transforming images from a remote origin or storing the originals inside Cloudflare Images.
**Short answer:** Cloudflare Images Free gives you **5,000 unique remote transformations per month**. After that, new Free-plan transforms fail with error `9422`; you are not silently charged. On Images Paid, remote-origin transforms cost **$0.50 per 1,000** after the first 5,000. If you store images inside Cloudflare Images, the bill changes to **$5 per 100,000 stored images** plus **$1 per 100,000 delivered images**.
[Cloudflare Images](https://developers.cloudflare.com/images/) has two use cases, and they are billed differently.
| Use case | Billing metric | Available on |
| | --- |
| Transform images stored outside Cloudflare Images | Images Transformed | Free and Paid |
| Store and serve images from Cloudflare Images | Images Stored + Images Delivered | Paid only |
This is the part most pricing comparisons get wrong.
If your originals live on R2, S3, WordPress, or your own server, Cloudflare bills the number of **unique transformations** requested in that calendar month. That means one source image plus one set of resizing, quality, format, or fit parameters.
If your originals are uploaded into Cloudflare Images, Cloudflare bills **stored images** and **delivered images** instead. Cloudflare's pricing page says that when you optimize an image stored in Images, it counts toward Images Delivered, not Images Transformed.
| Metric | Current Price | When it applies |
| --- | --- | --- |
| **Images Transformed** | First 5,000 included, then $0.50/1,000 on Paid | Remote images stored outside Cloudflare Images |
| **Images Stored** | $5/100,000 images/month | Originals uploaded to Cloudflare Images |
| **Images Delivered** | $1/100,000 delivered images/month | Browser requests for images stored in Cloudflare Images |
Canonical source: [https://theimagecdn.com/docs/cloudflare-images-pricing](https://theimagecdn.com/docs/cloudflare-images-pricing) — Markdown: [https://theimagecdn.com/docs/cloudflare-images-pricing.md](https://theimagecdn.com/docs/cloudflare-images-pricing.md)
---
## BunnyCDN Coupon Code 2026 — $5 Free Credit + Honest Stacking Guide
Working BunnyCDN coupon code for June 2026. Use THEWPX to get $5 free credit, see which extra codes are worth trying, and learn the real pricing catch before you sign up.
Use coupon code **THEWPX** on [BunnyCDN](https://try.sunnysah.com/BunnyCDN) to get **$5 in free credit** on a new bunny.net account. That is the code I would use first. The extra codes below are worth trying after signup, but I would not treat every public coupon list as guaranteed money.
**TL;DR:** The real BunnyCDN deal in June 2026 is simple: sign up, apply **THEWPX**, and get **$5 free credit**. BunnyCDN also gives a 14-day trial, and some accounts can stack additional $5 promo codes from the billing screen. The product is cheap enough that even $5 can cover a small site's CDN usage for months.
The code is **THEWPX**, and it gives **$5 in BunnyCDN credit** for new users. You do not get a percentage discount like "30% off forever." You get account credit that is used against BunnyCDN services.
That is actually better for testing.
You can use the credit for CDN bandwidth, Bunny Optimizer, Storage, Stream, DNS, and other bunny.net services. If you are setting up a small WordPress site or a new image CDN test, credit is more useful than a one-time cart discount.
Here is the important distinction.
A **coupon code** gives you credit. A **trial** gives you temporary trial balance. A **cash top-up** adds your own money. They all appear around billing, but they are not the same thing.
One code first. Then test the rest.
Canonical source: [https://theimagecdn.com/docs/bunnycdn-coupon](https://theimagecdn.com/docs/bunnycdn-coupon) — Markdown: [https://theimagecdn.com/docs/bunnycdn-coupon.md](https://theimagecdn.com/docs/bunnycdn-coupon.md)
---
## 7 Best Image CDNs for WordPress in 2026: Pricing, Plugins, and Setup
Compare the best WordPress image CDNs and plugins: BunnyCDN, ShortPixel, EWWW, Optimole, Jetpack, Cloudflare, and WP Compress. Current pricing, limits, setup notes, and honest use cases.
The best image CDN for most WordPress sites in 2026 is **BunnyCDN** because it gives you a clean WordPress plugin, predictable pricing, WebP optimization, and low per-GB delivery without forcing you into a full media platform. **ShortPixel** and **EWWW** are better when you want a WordPress-native image optimization plugin first and a CDN second. **Jetpack Site Accelerator** is the best true free option, but it is basic and has cache-purge limitations.
**TL;DR:** Use [BunnyCDN](https://try.sunnysah.com/BunnyCDN) for the best overall WordPress setup: $9.50/month for Optimizer plus CDN delivery starting at $0.01/GB in North America and Europe. Use code **THEWPX** for $5 free credit. Use ShortPixel if you care most about WordPress image compression and adaptive delivery. Use EWWW if you want a mature WordPress plugin with Easy IO CDN. Use Jetpack only when free matters more than control.
Here is the useful version of the comparison.
| Provider | WordPress fit | Small-site cost | WebP | AVIF | Free option | Main catch |
| | --- | --- | --- | --- | --- |
| **BunnyCDN** | Official plugin | ~$10/month with Optimizer | Yes | No | Trial / credit | Optimizer needed for image processing |
| **ShortPixel** | Dedicated image plugins | $9.99/month Unlimited | Yes | Yes | Limited free testing | CDN quota still matters |
| **EWWW Image Optimizer** | Mature WP plugin | $8/month Standard | Yes | Yes | Local optimization | Many settings; Easy IO is paid |
| **Optimole** | Dedicated WP plugin | Free to 2,000 visits; paid after | Yes | Yes | 2,000 monthly visits | Visit-based pricing |
| **Jetpack Site Accelerator** | Built into Jetpack | Free | Yes, served to supported browsers | No | Free | Limited control and no bulk purge |
| **Cloudflare** | Security/CDN platform | $0-20+ depending setup | Yes via paid image features | Depends on product | Free CDN | Not a dedicated WP image plugin |
| **WP Compress** | Hands-off WP optimization | $9+/month public plan | Yes | No | Limited / plan-dependent | Smaller ecosystem |
The right choice depends on how much control you want.
If you want a CDN in front of WordPress, pick BunnyCDN. If you want a plugin that manages image compression…
Canonical source: [https://theimagecdn.com/docs/best-image-cdns-for-wordpress](https://theimagecdn.com/docs/best-image-cdns-for-wordpress) — Markdown: [https://theimagecdn.com/docs/best-image-cdns-for-wordpress.md](https://theimagecdn.com/docs/best-image-cdns-for-wordpress.md)
---
## Image CDN for Next.js: Loaders, Static Export & Cost Math (2026)
A practical guide to using Bunny, ImageKit, Cloudflare, Netlify, Cloudinary, or a self-hosted image CDN with next/image in modern Next.js.
Next.js gives you a good image component, but it does not make the image delivery decision for you forever. The default optimizer is convenient on Vercel, Netlify has its own platform image CDN, static export needs an external optimizer, and custom loaders let you send the same `` component through Bunny, ImageKit, Cloudflare, Cloudinary, or your own imgproxy service.
**TL;DR:** Keep the default Next.js image optimizer if your site is small, deployed on Vercel, and the included image usage is enough. Use [Bunny Optimizer](https://try.sunnysah.com/BunnyCDN) if you want the cheapest simple CDN-backed loader. Use ImageKit if developer experience and a clean transformation API matter. Use Cloudflare Images if your site already sits behind Cloudflare. Use Netlify Image CDN if you deploy Next.js to Netlify. Use Cloudinary only when you need its media workflow features, not because it is the cheapest way to resize images.
Use this as the starting point:
| Situation | Best Fit | Why |
| | --- |
| Small Vercel site with modest image use | **Default Vercel optimizer** | No extra provider, no custom loader, works out of the box |
| Static-exported Next.js site | **Bunny, ImageKit, Cloudflare, or imgproxy** | There is no Next.js server optimizer in a pure static export |
| Next.js deployed on Netlify | **Netlify Image CDN** | Netlify's Next.js adapter wires image optimization into `next/image` |
| Lowest predictable optimizer cost | **Bunny Optimizer** | $9.50/month per website for Optimizer, bandwidth billed separately |
| Best developer URL API | **ImageKit** | Clean transformations, free tier, storage, and broader media tooling |
| Already using Cloudflare | **Cloudflare Images** | Good fit with Cloudflare routing, Workers, R2, and transformation pricing |
| Rich media workflow | **Cloudinary** | Smart crops, media management, background removal, and advanced transformations |
| Full control | **imgproxy or Thumbor** | You own the service, cache, security, and cost model |
The most common mistake is comparing all of these as if they are the same thing. They are not.
Vercel's optimizer is a hosting-platform feature. Netlify Image CDN is a hosting-platform …
Canonical source: [https://theimagecdn.com/docs/image-cdn-for-nextjs](https://theimagecdn.com/docs/image-cdn-for-nextjs) — Markdown: [https://theimagecdn.com/docs/image-cdn-for-nextjs.md](https://theimagecdn.com/docs/image-cdn-for-nextjs.md)
---
## Cloudinary vs ImageKit vs BunnyCDN: Which Image CDN Should You Use in 2026?
Cloudinary, ImageKit, and BunnyCDN compared by real pricing, image optimization features, developer workflow, WordPress fit, Next.js fit, and the honest catch with each one.
Cloudinary, ImageKit, and BunnyCDN are not three versions of the same product. Cloudinary is a full media platform. ImageKit is a developer-friendly image and video optimization platform. BunnyCDN is a low-cost CDN with an image optimizer add-on.
**TL;DR:** Use **BunnyCDN** if you want the cheapest practical image CDN for a blog, WordPress site, documentation site, or small ecommerce store. Use **ImageKit** if you need cleaner developer APIs, transformations, DAM storage, WebP, AVIF, and predictable plan-plus-overage billing. Use **Cloudinary** if your real problem is not just image delivery, but media management, video, approvals, folders, governance, and enterprise workflows.
If you want the broader market view, read the [best image CDNs comparison](/docs/best-image-cdns). If pricing is the main concern, the [paid image CDN pricing guide](/docs/paid-cdn-options) gives the full cost table. If you are choosing for a store, use the [image CDN for ecommerce guide](/docs/image-cdn-for-ecommerce).
Short answer: **BunnyCDN for cost, ImageKit for developer workflow, Cloudinary for media operations.**
| Situation | Best Pick | Why |
| | --- |
| Blog, affiliate site, documentation site | **BunnyCDN** | Lowest predictable cost for image delivery and optimization |
| WordPress site with normal traffic | **BunnyCDN** | Cheap CDN, easy setup, good enough image optimization |
| Next.js app with URL transformations | **ImageKit** | Better developer API and cleaner transform syntax |
| SaaS app with user uploads | **ImageKit** | DAM storage, upload workflow, transformations, and overages |
| Enterprise brand or media team | **Cloudinary** | Rich DAM, video, governance, add-ons, and team workflows |
| Purely cheapest image delivery | **BunnyCDN** | CDN starts at $0.01/GB in Europe and North America |
| Heavy video and asset management | **Cloudinary** | Broader platform, not just image resizing |
The common mistake is choosing Cloudinary because it has the biggest feature list.
That feature list is useful if you need a media platform. It is expensive noise if all you want is compressed product images.
This is where the comparison becomes real.
Canonical source: [https://theimagecdn.com/docs/cloudinary-vs-imagekit-vs-bunnycdn](https://theimagecdn.com/docs/cloudinary-vs-imagekit-vs-bunnycdn) — Markdown: [https://theimagecdn.com/docs/cloudinary-vs-imagekit-vs-bunnycdn.md](https://theimagecdn.com/docs/cloudinary-vs-imagekit-vs-bunnycdn.md)
---
## Why Your Image CDN Is Not Improving LCP: 7 Configuration Mistakes
Installed an image CDN but Largest Contentful Paint is still bad? Here are the seven configuration mistakes that usually block LCP gains, with fixes for HTML, WordPress, and Next.js.
Your image CDN is probably working. Your LCP setup may not be.
That is the part most people miss.
An image CDN can resize, compress, convert, cache, and deliver the LCP image faster. But it cannot fully fix a hero image that the browser discovers late, lazy-loads by mistake, renders after JavaScript, or requests at the wrong size.
**TL;DR:** If an image CDN is not improving LCP, check the LCP subparts before blaming the provider. The common mistakes are lazy-loading the hero image, missing `srcset` and `sizes`, late CSS or JavaScript discovery, no `fetchpriority`, too many cold-cache variants, a new third-party CDN connection, and render delay from CSS or JavaScript. The CDN mainly fixes image bytes and delivery. Your markup fixes discovery and priority.
Do not start by changing CDN providers.
Start by opening PageSpeed Insights, Chrome DevTools Performance, or WebPageTest and identifying the actual LCP element. Then check the LCP breakdown.
Google's [LCP optimization guide](https://web.dev/articles/optimize-lcp) breaks the metric into four parts:
| LCP part | What it means | Does an image CDN fix it? |
| | --- |
| TTFB | Time until HTML starts arriving | Not directly |
| Resource load delay | Time before the LCP image request starts | Only indirectly |
| Resource load duration | Time spent downloading the image | **Yes, this is the main CDN win** |
| Element render delay | Time after image load before it renders | No |
Canonical source: [https://theimagecdn.com/docs/why-image-cdn-not-improving-lcp](https://theimagecdn.com/docs/why-image-cdn-not-improving-lcp) — Markdown: [https://theimagecdn.com/docs/why-image-cdn-not-improving-lcp.md](https://theimagecdn.com/docs/why-image-cdn-not-improving-lcp.md)
---
## Progressive JPEG vs Baseline JPEG - Which Should You Use?
Progressive JPEG shows a blurry full-image preview before sharpening. Baseline JPEG paints top to bottom. Learn which JPEG encoding is better for web images, fallbacks, and perceived speed.
Progressive JPEG and baseline JPEG store the same kind of JPEG image data, but they load differently. Baseline JPEG paints from top to bottom. Progressive JPEG shows a blurry full-image preview first, then sharpens it in passes. For most web JPEG fallbacks, progressive JPEG is the better default.
**TL;DR:** Use **progressive JPEG** for most JPEG images over tiny-thumbnail size. It usually feels faster because users see the whole image early, and it is often slightly smaller than baseline JPEG. Use **baseline JPEG** only for very small images, legacy workflows, or cases where decode simplicity matters. For modern websites, serve **WebP or AVIF first** and keep progressive JPEG as the fallback through a `` element or [image CDN format negotiation](/docs/can-image-cdn-convert-formats).
For normal web images, progressive JPEG is usually better.
| Situation | Better choice | Why |
| | --- |
| Large hero image fallback | **Progressive JPEG** | Users see a full preview sooner |
| Product photo fallback | **Progressive JPEG** | Better perceived loading on slower networks |
| Blog image fallback | **Progressive JPEG** | Good default for medium/large JPEGs |
| Tiny thumbnails/icons | **Baseline JPEG** | Progressive overhead can outweigh benefits |
| Very old or constrained devices | **Baseline JPEG** | Simpler decode path |
| Modern optimized site | **AVIF/WebP first, progressive JPEG fallback** | Better than choosing JPEG alone |
The important word is "fallback."
If a browser supports WebP or AVIF, those are usually better delivery formats than either JPEG encoding. The [WebP vs AVIF vs JPEG guide](/docs/webp-vs-avif-vs-jpeg) covers that broader decision.
Progressive JPEG still matters because JPEG is not dead. HTTP Archive's [2024 Media chapter](https://almanac.httparchive.org/en/2024/media) reported JPEG at **32.4% of mobile image resources**. Many sites still need JPEG fallbacks, email images, CMS uploads, and legacy support.
Both are JPEG. Both use lossy JPEG compression. The difference is how the compressed data is arranged and decoded during download.
Canonical source: [https://theimagecdn.com/docs/progressive-jpeg-vs-baseline-jpeg](https://theimagecdn.com/docs/progressive-jpeg-vs-baseline-jpeg) — Markdown: [https://theimagecdn.com/docs/progressive-jpeg-vs-baseline-jpeg.md](https://theimagecdn.com/docs/progressive-jpeg-vs-baseline-jpeg.md)
---
## Lossy vs Lossless Compression - When to Use Each for Web Images
Lossy compression makes photos much smaller by discarding visual data. Lossless compression keeps every pixel. Learn when to use JPEG, PNG, WebP, AVIF, and lossless formats on the web.
Lossy compression makes images smaller by permanently discarding data. Lossless compression makes images smaller without losing a single pixel. Use lossy for photos and complex visuals. Use lossless for screenshots, logos, text, diagrams, transparency, and source files you may edit again.
**TL;DR:** Use **lossy compression** for photos, product images, hero images, backgrounds, and thumbnails. JPEG, lossy WebP, and AVIF are built for this. Use **lossless compression** for screenshots, logos, UI mockups, diagrams, icons, transparent graphics, and source files. PNG, lossless WebP, and JPEG XL are built for that. Most websites need both, and an [image CDN](/docs/best-image-cdns) can choose the right output per image and browser.
Lossy compression removes image data permanently. The encoder tries to remove details the human eye is less likely to notice, such as tiny color changes, high-frequency noise, and detail in busy areas. The result can look almost identical at normal viewing size, but it is not the original image anymore.
Lossless compression keeps the original image exactly recoverable. It finds repeated patterns, predicts pixel values, and stores the same data more efficiently. When you decode a lossless image, you get the same pixels back.
| Question | Lossy compression | Lossless compression |
| | --- |
| Does it discard data? | Yes | No |
| Can the original be perfectly restored? | No | Yes |
| Best for | Photos and complex visuals | Text, logos, screenshots, diagrams |
| Typical web formats | JPEG, lossy WebP, AVIF | PNG, lossless WebP, JPEG XL |
| File-size savings | Usually much larger | Smaller, but exact |
| Visible risk | Artifacts, banding, blurred edges | Larger files |
| Editing workflow | Final export only | Source and intermediate files |
The key point is not that one is better. The key point is that they solve different jobs.
Lossy compression is better when visual similarity is enough. Lossless compression is better when exact pixels matter.
JPEG is the easiest format to understand because it shows the classic lossy workflow.
Canonical source: [https://theimagecdn.com/docs/lossy-vs-lossless-compression](https://theimagecdn.com/docs/lossy-vs-lossless-compression) — Markdown: [https://theimagecdn.com/docs/lossy-vs-lossless-compression.md](https://theimagecdn.com/docs/lossy-vs-lossless-compression.md)
---
## Lazy Loading Images with an Image CDN - The Practical Guide
Lazy loading delays below-the-fold images. An image CDN resizes, compresses, and converts the images that do load. Here is how to use both without hurting LCP.
Lazy loading and image CDNs solve different problems. Lazy loading controls **when** images download. An image CDN controls **how big** those images are and **where** they are served from. Used together, they can make image-heavy pages much lighter. Used badly, they can delay your hero image and hurt LCP.
**TL;DR:** Add `loading="lazy"` only to images below the first viewport. Do **not** lazy-load your hero image, product lead image, or any likely LCP image. Give the LCP image normal eager loading, correct dimensions, and usually `fetchpriority="high"`. Then serve all images through an [image CDN](/docs/best-image-cdns) for resizing, WebP/AVIF conversion, compression, and caching. Lazy loading saves unnecessary downloads. The CDN makes necessary downloads smaller.
Use this as the default pattern.
| Image type | Loading behavior | Why |
| | --- |
| Hero image / likely LCP image | Eager, often `fetchpriority="high"` | It must start loading early |
| Site logo | Eager | Small and visible immediately |
| First product image | Eager | Usually important above the fold |
| Images below the first viewport | `loading="lazy"` | Avoid unnecessary downloads |
| Gallery images after the first visible row | `loading="lazy"` | User may never scroll to them |
| Footer, related posts, comments, ads | `loading="lazy"` | Low initial priority |
| CSS background images | Custom handling | `loading="lazy"` does not apply to CSS backgrounds |
The image CDN is separate from that decision.
- resizing by viewport
- WebP/AVIF conversion
- JPEG/PNG fallback
- compression
- caching
- delivery from a nearby edge location
Lazy loading does not optimize an image file. It only delays the request. A 2 MB image is still a 2 MB image when it finally loads. That is why lazy loading and an image CDN belong together.
Lazy loading reduces the number of images downloaded during initial page load.
Canonical source: [https://theimagecdn.com/docs/lazy-loading-image-cdn](https://theimagecdn.com/docs/lazy-loading-image-cdn) — Markdown: [https://theimagecdn.com/docs/lazy-loading-image-cdn.md](https://theimagecdn.com/docs/lazy-loading-image-cdn.md)
---
## Will an Image CDN Make My Website Faster? Usually, If Images Are The Bottleneck
Image CDNs can make websites faster by resizing, compressing, converting, caching, and delivering images from the edge. Learn when the speed gains are real and when they are limited.
Yes, an image CDN can make your website faster. But the honest answer is conditional: it helps most when images are large, unoptimized, remote from users, or used as the LCP element. It helps less when your bottleneck is JavaScript, server response time, third-party scripts, fonts, or database work.
**TL;DR:** An image CDN speeds up a site by doing five jobs: resizing images to the right dimensions, compressing them, converting to WebP/AVIF when useful, caching transformed variants, and serving them from edge locations. Expect the biggest gains on ecommerce, portfolios, blogs, recipe sites, docs with screenshots, and mobile-heavy pages. Do not expect a CDN to fix slow JavaScript, bad hosting, render-blocking CSS, or missing image dimensions by itself.
An image CDN will probably make your website faster if:
- Images are the largest resources on your pages.
- Your LCP element is an image.
- Mobile users download desktop-sized images.
- You still serve JPEG/PNG instead of WebP/AVIF.
- You have visitors far from your origin server.
- Your origin gets slow under image traffic.
- You have many thumbnails, product images, screenshots, or gallery images.
- Editors upload oversized media.
It may not make a noticeable difference if:
- Your pages are mostly text.
- Images are already optimized at build time.
- You already serve correct `srcset`, `sizes`, WebP/AVIF, and long cache headers.
- Your biggest problem is JavaScript execution.
- Your server response time is slow before images even start loading.
- Your LCP is text, not an image.
- You only have a few small icons.
The fastest way to know is to measure the page's network waterfall with [PageSpeed Insights](https://pagespeed.web.dev/), Chrome DevTools, or WebPageTest. If images dominate transfer size or LCP, an image CDN is a good candidate. If JavaScript dominates main-thread time, start elsewhere.
An image CDN is faster because it changes the actual bytes and delivery path. A traditional CDN mostly moves files closer to users. An image CDN also changes the files.
Canonical source: [https://theimagecdn.com/docs/will-image-cdn-make-website-faster](https://theimagecdn.com/docs/will-image-cdn-make-website-faster) — Markdown: [https://theimagecdn.com/docs/will-image-cdn-make-website-faster.md](https://theimagecdn.com/docs/will-image-cdn-make-website-faster.md)
---
## Quick CDN Startup Guide: Set Up BunnyCDN the Right Way
A practical BunnyCDN setup guide for WordPress, static sites, and custom apps. Create a pull zone, connect your site, enable image optimization, and verify the CDN is actually working.
This is the fast path for setting up BunnyCDN without overcomplicating it. You will create a pull zone, connect your site, optionally add image optimization, and verify that assets are actually loading through the CDN.
Short answer: for most WordPress, static, and marketing sites, BunnyCDN setup is a 15-30 minute job.
If images still load from your origin, you did not set up a CDN. If images load through BunnyCDN but stay oversized, you set up delivery but not image optimization.
BunnyCDN has two separate ideas that people often mix up.
**BunnyCDN pull zone:** caches and serves your files from Bunny's edge network.
**Bunny Optimizer:** adds image optimization on top of delivery.
If you only create a pull zone, a 2 MB JPEG still gets delivered as a 2 MB JPEG. It may arrive from a closer server, but the file itself is unchanged.
If you enable image optimization, Bunny can compress images and serve better variants depending on your settings.
Canonical source: [https://theimagecdn.com/docs/quick-startup-guide](https://theimagecdn.com/docs/quick-startup-guide) — Markdown: [https://theimagecdn.com/docs/quick-startup-guide.md](https://theimagecdn.com/docs/quick-startup-guide.md)
---
## Free vs Paid Image CDNs: When Free Stops Being Enough
A practical comparison of free and paid image CDNs, including ImageKit, Cloudflare Images, BunnyCDN, Imgix, and Uploadcare. Learn when to stay free and when to upgrade.
Free image CDNs are good for testing, small blogs, prototypes, and low-risk projects. Paid image CDNs are worth it when broken images, hard limits, missing custom domains, or unpredictable traffic spikes would actually hurt you.
- Use free if the site is small and non-critical.
- Use paid if the site earns revenue.
- Use paid if image delivery must not stop mid-month.
- Use paid if you need predictable overages, custom domains, or support.
The mistake is treating "free" as a strategy.
It is not always a production plan.
| Setup | Best for | What to watch |
| | --- |
| **ImageKit Free** | Small blogs, portfolios, testing | 20 GB bandwidth cap; delivery stops when hit |
| **Cloudflare Images Free** | Small image libraries on Cloudflare | 5,000 unique transformations/month |
| **BunnyCDN promo credit** | Testing BunnyCDN delivery | Credit runs out; then you need billing |
| **ImageKit Lite** | Low-cost developer-friendly upgrade | 40 GB included, then bandwidth/storage overage |
| **BunnyCDN + Optimizer** | Predictable paid setup for normal sites | CDN bandwidth plus $9.50/site Optimizer |
| **Cloudflare Images Paid** | Cloudflare/R2/Workers-heavy stacks | Transform, storage, and delivery billing differ |
| **Imgix / Uploadcare / Cloudinary** | Apps, uploads, DAM, media workflows | Higher platform-style pricing |
**Free plans limit risk for you.**
**Paid plans limit risk for your visitors.**
Stay free when the project is still small or non-critical.
Canonical source: [https://theimagecdn.com/docs/free-vs-paid-image-cdns](https://theimagecdn.com/docs/free-vs-paid-image-cdns) — Markdown: [https://theimagecdn.com/docs/free-vs-paid-image-cdns.md](https://theimagecdn.com/docs/free-vs-paid-image-cdns.md)
---
## CDN for Pictures: What It Means and How to Set It Up
A CDN for pictures is an image delivery layer that caches, resizes, compresses, and converts photos before sending them to visitors. Here is what it does, when you need one, and how to choose a setup.
Short answer: a CDN for pictures is an image delivery layer for your website photos. It stores image variants near visitors, resizes them for the screen, compresses them, and serves WebP or AVIF when the browser supports it.
If you searched "CDN pictures" because you wanted free stock photos, this is not the right tool. Use [Unsplash](https://unsplash.com), [Pexels](https://www.pexels.com), Pixabay, or [Freepik](https://www.freepik.com/free-photos-vectors/cdn).
If you searched because your website images are slow, this guide is for you.
- Use **ImageKit** if you want a strong free tier and quick setup.
- Use **BunnyCDN + Optimizer** if you want low-cost paid delivery with unlimited image optimization.
- Use **Cloudflare Images** if your site already lives inside the Cloudflare stack.
- Use **Cloudinary, Imgix, Sirv, or Uploadcare** when you need deeper media workflow features, not just faster image delivery.
"CDN pictures" is a messy search phrase.
It usually means one of two things:
| What you want | Use this |
| |
| Free photos to download | Unsplash, Pexels, Pixabay, Freepik |
| A way to make your own website photos load faster | Image CDN / picture CDN |
| A place to share images publicly | Imgur, Postimage |
| Product image hosting with transformations | Cloudinary, ImageKit, Sirv, Uploadcare |
| A cheap cache for existing image files | BunnyCDN, Cloudflare CDN |
This article covers the second meaning: serving your own images faster.
Canonical source: [https://theimagecdn.com/docs/cdn-pictures](https://theimagecdn.com/docs/cdn-pictures) — Markdown: [https://theimagecdn.com/docs/cdn-pictures.md](https://theimagecdn.com/docs/cdn-pictures.md)
---
## Can Using an Image CDN Hurt Your SEO? Only If You Misconfigure It
Image CDNs usually help SEO by improving page experience and image delivery. Learn the real risks: blocked crawlers, broken image URLs, missing alt text, and bad redirects.
An image CDN does not hurt SEO by default. In most cases, it helps because images load faster, pages get lighter, and Core Web Vitals improve. The SEO risk comes from migration mistakes: blocked crawlers, broken image URLs, stripped alt text, missing dimensions, and CDN security rules that treat Googlebot like a bad bot.
**TL;DR:** Use an image CDN if images are slowing down your site. Google can crawl and index CDN-hosted images, image sitemap URLs can point to a CDN domain, and serving images from a subdomain is normal. The setup becomes risky only when old image URLs 404, Googlebot is blocked, `alt` text disappears, image dimensions are removed, or the CDN generates unstable URLs. Keep the HTML clean, verify the CDN domain in Search Console, preserve image attributes, and test crawlability after launch.
Image CDNs are SEO-safe when they are configured like normal web infrastructure.
Google does not penalize a page because an image is served from `cdn.example.com`, `images.example.com`, `example.b-cdn.net`, Cloudinary, ImageKit, Cloudflare, or another image host. Major sites have served images from CDN domains for years.
The ranking value does not come from the CDN hostname. It comes from the result:
- Faster LCP.
- Smaller image transfer sizes.
- Better mobile page experience.
- Fewer origin bottlenecks.
- More consistent image delivery.
- Crawlable image URLs.
- Descriptive alt text and surrounding content.
Google's [page experience docs](https://developers.google.com/search/docs/appearance/page-experience) are worth reading carefully. Google says Core Web Vitals are used by its ranking systems, but also says there is no single "page experience signal" and that great page experience does not guarantee top rankings. Relevance and content quality still lead.
An image CDN can help SEO when images are a performance bottleneck. It will not rescue weak content, poor internal linking, bad search intent matching, or a broken site architecture. It also can hurt SEO if you botch the migration.
Canonical source: [https://theimagecdn.com/docs/can-image-cdns-hurt-seo](https://theimagecdn.com/docs/can-image-cdns-hurt-seo) — Markdown: [https://theimagecdn.com/docs/can-image-cdns-hurt-seo.md](https://theimagecdn.com/docs/can-image-cdns-hurt-seo.md)
---
## Free Image Tools: Online Converters and Optimizers
Free online image and PDF tools that run in your browser. Convert JPEG/PNG/WebP/HEIC, compress images in bulk, combine images into PDFs, and analyze PDF files. No uploads, no server — everything happens locally.
Free online image and PDF tools that run entirely in your browser. Convert, compress, and transform files without uploading anything to a server — your images never leave your device.
Every tool on this page runs locally in your browser using WebAssembly and the Canvas API. That means:
- **Privacy**: files never leave your device — no uploads, no servers, no logs
- **Speed**: no upload/download round-trip, so conversion starts instantly
- **No size limits**: only constrained by your device's memory, not a server quota
- **Works offline**: once the page loads, you can disconnect and keep working
If you're building a site that serves images to real users, a browser converter handles the one-off job but an [image CDN](/docs/best-image-cdns) is what you want in production — it auto-converts to WebP/AVIF based on the visitor's browser, resizes on the fly, and caches globally.
Related reading: [WebP vs AVIF vs JPEG](/docs/webp-vs-avif-vs-jpeg) · [Free vs paid image CDNs](/docs/free-vs-paid-image-cdns) · [Do I need a CDN?](/docs/do-i-need-cdn)
Canonical source: [https://theimagecdn.com/tools](https://theimagecdn.com/tools) — Markdown: [https://theimagecdn.com/tools.md](https://theimagecdn.com/tools.md)
---
## Free WebP to PNG Converter - Browser-Based, No Upload Required
Convert WebP images to PNG directly in your browser. Batch conversion, transparency preserved, no server upload, no account, no watermark.
Convert WebP images to PNG directly in your browser. No upload, no account, no watermark. The converter runs locally with the Canvas API and keeps transparent backgrounds.
**TL;DR:** Use this when a tool, client, CMS, print workflow, or older app needs PNG instead of WebP. The PNG will often be larger. That is normal: this conversion is about compatibility, not making the file smaller.
1. Click **"Choose Files"** or drag and drop WebP images
2. Select one file or a batch
3. Click **"Convert to PNG"**
4. Download each PNG or use **"Download all"**
Your files stay in the browser. The tool decodes the WebP, draws the image to a canvas, and exports a PNG copy locally.
This tool converts the decoded WebP pixels into PNG using [`canvas.toBlob()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob). PNG is lossless, so the PNG output preserves the pixels as they exist after the WebP is decoded.
Important distinction: converting WebP to PNG does not restore detail that was already lost in a lossy WebP. It only gives you a PNG version of the decoded WebP image.
| Need | What happens here |
| |
| Compatibility | WebP is exported as PNG |
| Transparency | Alpha channel is preserved |
| Batch conversion | Multiple WebP files convert in one run |
| Privacy | Files stay in your browser; no server receives them |
| Source preservation | Original WebP files remain untouched |
Google's WebP documentation describes WebP as supporting lossy, lossless, animation, and transparency. PNG is simpler: it is the safe compatibility format when another tool refuses WebP.
Canonical source: [https://theimagecdn.com/tools/webp-to-png](https://theimagecdn.com/tools/webp-to-png) — Markdown: [https://theimagecdn.com/tools/webp-to-png.md](https://theimagecdn.com/tools/webp-to-png.md)
---
## Free PNG to WebP Converter - Browser-Based, No Upload Required
Convert PNG images to WebP directly in your browser. Batch conversion, transparency preserved, no server upload, no account, no hard file-size limit.
Convert PNG images to WebP directly in your browser. No upload, no account, no watermark. The converter uses your browser's Canvas API, so your files stay on your device and your original PNGs are not modified.
**TL;DR:** Drop your PNG files below, keep quality around 80% for most web graphics, and download smaller WebP copies. Transparency is preserved. If the PNG is a source file for editing, keep it; use the WebP for delivery on the web.
1. Click **"Choose Files"** or drag and drop your PNG images
2. Select one PNG or a full batch
3. Set the **quality slider** - 80% is a good default for most web graphics
4. Click **"Convert to WebP"**
5. Download each file or use **"Download all"**
The file is decoded and re-encoded locally in your browser. There is no upload step, which matters for private mockups, client designs, unreleased product images, internal screenshots, and legal or medical documents.
This tool converts PNG files into quality-based WebP files using [`canvas.toBlob()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob). MDN documents that `toBlob()` can export supported browser image types and accepts a quality value for formats such as JPEG and WebP.
That detail matters: this browser tool is not a specialist archival encoder. It is built for web delivery, quick testing, and batch conversion. If you need mathematically lossless WebP output for archival work, use Google's `cwebp -lossless` command-line tool or an image pipeline that exposes true lossless WebP settings.
For normal website images, the browser approach is the useful one:
| Need | What happens here |
| |
| Smaller web assets | PNG is exported as WebP with your chosen quality |
| Transparent background | Alpha is retained in the exported WebP |
| Batch conversion | Multiple PNGs convert in one run |
| Privacy | Files stay in the browser; no server receives them |
| Source preservation | Original PNG files remain untouched |
Canonical source: [https://theimagecdn.com/tools/png-to-webp](https://theimagecdn.com/tools/png-to-webp) — Markdown: [https://theimagecdn.com/tools/png-to-webp.md](https://theimagecdn.com/tools/png-to-webp.md)
---
## Free PDF Compressor and Analyzer - Browser-Based, No Upload
Analyze and lightly optimize PDF files directly in your browser. No upload, no account, metadata preview, page details, and private lossless rewrite.
Analyze and lightly optimize PDF files directly in your browser. No upload, no account, no server processing. The tool shows page count, dimensions, metadata, file size, and downloads an optimized copy only when a local lossless rewrite makes the PDF smaller.
**TL;DR:** This is a privacy-first PDF analyzer with a conservative optimization pass. It can help with metadata-heavy or structurally bloated PDFs, but it does not aggressively recompress scanned pages or embedded photos. For image-heavy PDFs, compress the images before building the PDF or use a dedicated desktop/server compressor.
1. Click **"Choose PDFs"** and select one or more PDF files
2. Click **"Analyze & Optimize"**
3. Review page count, dimensions, creator metadata, recommendations, and file-size result
4. Download the optimized copy if one is available
If the tool does not show a download button for a file, the local rewrite did not make that PDF smaller.
This tool uses `pdf-lib` in the browser to load each PDF, inspect basic document information, and save a rewritten copy using object streams. It is a lossless structural pass, not an aggressive image recompressor.
| Need | What happens here |
| |
| Privacy | PDF files stay in your browser |
| Analysis | Page count, file size, dimensions, creator, title, author, and subject are shown |
| Optimization | A local rewrite is attempted |
| Download | Offered only if the rewritten PDF is smaller |
| Batch work | Multiple PDFs can be processed in one run |
The practical limit: most huge PDFs are huge because of scanned pages or embedded images. This browser tool does not downsample those images. That is intentional; it avoids silently damaging document quality.
Expect modest results. Sometimes the optimized file is smaller. Sometimes it is the same size. Sometimes the best answer is "do not touch this PDF here."
Canonical source: [https://theimagecdn.com/tools/pdf-compressor](https://theimagecdn.com/tools/pdf-compressor) — Markdown: [https://theimagecdn.com/tools/pdf-compressor.md](https://theimagecdn.com/tools/pdf-compressor.md)
---
## Free JPG to PDF Converter - Browser-Based, No Upload Required
Combine JPEG and PNG images into one PDF directly in your browser. Multi-page output, page size control, margins, no upload, no account.
Combine JPEG and PNG images into one PDF directly in your browser. Choose fit-to-image, A4, Letter, or Legal page size, set a margin, and download a multi-page PDF. Nothing is uploaded.
**TL;DR:** Use this when a form, client, school, bank, or workflow wants one PDF instead of separate images. Each selected image becomes one page. This tool packages images into a PDF; it is not a deep PDF compressor.
1. Click **"Choose Files"** and select JPEG or PNG images
2. Pick a page size: **fit**, **A4**, **Letter**, or **Legal**
3. Set the margin in points
4. Click **"Build PDF"**
5. Download the generated PDF
Files combine in the order your browser provides them from the file picker. If order matters, rename files before selecting them, for example `01-front.jpg`, `02-back.jpg`, `03-receipt.jpg`.
This tool uses `pdf-lib` in your browser to create a new PDF and embed each selected image as a page.
| Need | What happens here |
| |
| One PDF from many images | Each image becomes one page |
| Standard paper output | A4, Letter, and Legal are available |
| Native image size | Fit-to-image keeps the page close to the image dimensions |
| Privacy | Files stay in your browser; no server receives them |
| Compression | Images are embedded; they are not aggressively recompressed |
JPEG inputs are embedded as JPEG. PNG inputs are embedded as PNG. That keeps the workflow predictable, but it also means the output PDF size mostly depends on the size of the source images.
Use this converter when one PDF is easier to submit, share, print, or archive than many image files.
Canonical source: [https://theimagecdn.com/tools/jpg-to-pdf](https://theimagecdn.com/tools/jpg-to-pdf) — Markdown: [https://theimagecdn.com/tools/jpg-to-pdf.md](https://theimagecdn.com/tools/jpg-to-pdf.md)
---
## JPEG to WebP Converter - Free, Local, Batch
Convert JPEG and JPG images to WebP directly in your browser. Batch conversion, adjustable quality, no server upload, no account, no watermark.
Convert JPEG and JPG images to WebP directly in your browser. No upload, no account, no watermark. The converter runs locally with the Canvas API, so your original files stay on your device.
**TL;DR:** Drop your JPEG files below, keep quality around 80% for most photos, and download WebP copies for faster website delivery. Results vary by image, but Google documents WebP lossy images as 25-34% smaller than comparable JPEGs at equivalent quality.
1. Click **"Choose Files"** or drag and drop JPEG/JPG images
2. Select one file or a batch
3. Set the **quality slider** - 80% is a good default for web photos
4. Click **"Convert to WebP"**
5. Download each file or use **"Download all"**
The converter does not upload your images. Your browser reads the file, decodes it, draws it to a canvas, and exports a new `.webp` file locally.
This tool re-encodes JPEG pixels into WebP using [`canvas.toBlob()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob). MDN documents that `toBlob()` accepts a format type and a quality value for lossy formats such as JPEG and WebP.
That makes this tool a good fit for quick web optimization:
| Need | What happens here |
| |
| Smaller website images | JPEG is exported as WebP at your chosen quality |
| Batch conversion | Multiple JPEG/JPG files convert in one run |
| Privacy | Files stay in your browser; no server receives them |
| Simple workflow | No install, account, queue, or watermark |
| Source preservation | Original JPEG files remain untouched |
- **Metadata is usually stripped.** Canvas export creates a new image from pixels, so EXIF fields such as GPS location, camera model, and copyright metadata are normally not preserved. For web delivery, that is often useful. For archival workflows, keep the original JPEG.
- **It uses the browser encoder.** Chrome, Safari, Firefox, and Edge may not produce byte-identical output. If you need exact encoder flags, use `cwebp`, Squoosh, Sharp, or your image CDN pipeline.
Canonical source: [https://theimagecdn.com/tools/jpeg-to-webp](https://theimagecdn.com/tools/jpeg-to-webp) — Markdown: [https://theimagecdn.com/tools/jpeg-to-webp.md](https://theimagecdn.com/tools/jpeg-to-webp.md)
---
## Free Bulk Image Compressor - Browser-Based WebP, JPEG, PNG Output
Compress JPEG, PNG, WebP, GIF, and BMP images in your browser. Batch conversion, adjustable quality, no upload, no account, no watermark.
Compress JPEG, PNG, WebP, GIF, and BMP images in bulk directly in your browser. Choose WebP, JPEG, or PNG output, set quality once, and download the converted files. Nothing is uploaded.
**TL;DR:** Use WebP output for most website images, JPEG output when compatibility matters, and PNG output when you need lossless files. This is best for one-off batches. For a production site, use an [image CDN](/docs/best-image-cdns) so resizing, format negotiation, compression, and caching happen automatically.
1. Click **"Choose Files"** and select one or more images
2. Pick **WebP**, **JPEG**, or **PNG** output
3. Set quality - 80% is a good default for WebP and JPEG
4. Click **"Compress"**
5. Download each file or use **"Download all"**
The tool runs locally. Your files are decoded in the browser, redrawn to a canvas, and exported as the format you selected.
This is a browser-based re-encoder using the Canvas API. It reads each image, draws the decoded pixels to a canvas, then exports a new WebP, JPEG, or PNG file.
| Need | What happens here |
| |
| Batch work | One setting applies to all selected images |
| Web delivery | WebP output is the usual default |
| Compatibility | JPEG output works almost everywhere |
| Lossless output | PNG output keeps decoded pixels lossless |
| Privacy | Files stay in your browser; no server receives them |
- **Metadata is usually stripped.** EXIF, GPS, camera data, and copyright metadata normally do not survive Canvas export.
- **GIF animation is not preserved.** Animated GIF input is decoded as a still image frame, then exported as WebP, JPEG, or PNG.
- **PNG ignores the quality slider.** PNG output is lossless; quality only affects WebP and JPEG.
- **Some files can grow.** Already-optimized images, tiny icons, and palette PNGs may not get smaller.
| Workflow | Pick | Why |
| --- | --- | --- |
| Website images | **WebP** | Good balance of size, quality, transparency, and modern browser support |
| Email, documents, old apps | **JPEG** | Opens almost everywhere |
| Lossless screenshots, source files, compatibility graphics | **PNG** | Preserves decoded pixels without lossy compression |
Canonical source: [https://theimagecdn.com/tools/image-compressor](https://theimagecdn.com/tools/image-compressor) — Markdown: [https://theimagecdn.com/tools/image-compressor.md](https://theimagecdn.com/tools/image-compressor.md)
---
## Free HEIC to JPG Converter - Browser-Based iPhone Photo Converter
Convert iPhone HEIC and HEIF photos to JPG directly in your browser. Batch conversion, adjustable JPEG quality, no upload, no account, no watermark.
Convert HEIC and HEIF photos from iPhone, iPad, and Mac to JPG directly in your browser. No upload, no account, no watermark. The converter runs locally and keeps your original HEIC files unchanged.
**TL;DR:** Drop HEIC files below, keep JPEG quality around 85% for normal sharing, and download JPG copies that open almost everywhere. HEIC is efficient, but JPG is still the safer handoff format for Windows users, web forms, older apps, email attachments, and client delivery.
1. Click **"Choose Files"** or drag and drop `.heic` / `.heif` photos
2. Select one photo or a batch
3. Set **JPEG quality** - 85% is a good default
4. Click **"Convert to JPG"**
5. Download each file or use **"Download all"**
The decoder runs in your browser. Your photos are not uploaded to a conversion server.
This tool uses the `heic2any` browser package to decode HEIC/HEIF files and output JPEG blobs locally. It is built for practical compatibility: take an iPhone photo format that many tools reject, turn it into a JPG, and keep the original HEIC untouched.
| Need | What happens here |
| |
| iPhone photo compatibility | HEIC/HEIF is exported as JPG |
| Batch conversion | Multiple photos convert in one run |
| Quality control | JPEG quality slider controls output size and fidelity |
| Privacy | Files stay in your browser; no server receives them |
| Source preservation | Original HEIC files remain untouched |
Apple says iOS 11 and macOS High Sierra introduced HEIF/HEVC support for photos and video, and that HEIF/HEVC use less storage while preserving visual quality. Apple also documents manual export to JPEG or PNG from Photos or Preview when compatibility is needed.
HEIC is efficient inside the Apple ecosystem. JPG is easier everywhere else.
Canonical source: [https://theimagecdn.com/tools/heic-to-jpg](https://theimagecdn.com/tools/heic-to-jpg) — Markdown: [https://theimagecdn.com/tools/heic-to-jpg.md](https://theimagecdn.com/tools/heic-to-jpg.md)