files.link vs Cloudinary: When You Don't Need Transforms
Cloudinary is image/video management with on-the-fly transforms. files.link is storage + CDN only. Honest guide to when each saves you money.
Cloudinary's core value
Cloudinary's superpower is URL-driven media transformation. You upload one master image; the URL parameters give you back any size, crop, format, or AI-tagged variant on demand. Need a 200×200 WebP for a thumbnail? /upload/w_200,h_200,c_fill,f_auto/myimage and you're done. The CDN caches the result.
For teams managing thousands of images with many variants, this is genuinely powerful. You don't write a resizing pipeline; Cloudinary's edge does it for you.
What you pay for
That magic isn't free. Cloudinary's pricing layers storage + bandwidth + transformations as separate metered dimensions. A single image with 5 size variants × 3 formats counts as 15 transformations the first time each is requested. Heavy galleries can blow through free / cheap tiers quickly.
If you ARE using transforms heavily, Cloudinary is probably the right tool — building your own image resizing pipeline is a real engineering project.
If you're NOT using transforms (you've already pre-rendered your variants with sharp in a build step, or you only need to serve one canonical size per asset), you're paying the Cloudinary tax for features you don't use.
files.link wins when transforms happen elsewhere
files.link is storage + CDN. Bytes in, bytes out. If you handle image processing before upload (sharp, ImageMagick, browser canvas, a build-time worker), files.link serves the pre-rendered variants from a global CDN at flat per-GB rates.
The honest workflow: convert and resize locally → upload each variant as a separate file → reference them with <picture> srcset or <img> tags. You write the resize code once (or use sharp's well-trodden defaults), pay only for storage + bandwidth, and skip the per-transformation billing dimension.
For sites with <50 unique images, this is fine. For sites with thousands, Cloudinary's on-demand model probably wins.
Hybrid is fine too
Some teams use Cloudinary for the dynamic image-heavy parts of their site (user-uploaded photos that need many variants) and files.link for everything else (PDFs, videos, downloadable assets, static images). The two coexist — different jobs, different tools.
For dev-first storage + CDN without the per-transformation fees, files.link as a Cloudinary alternative is the framing. For URL-driven image processing, Cloudinary is the right call.