UploadThing vs Cloudinary vs AWS S3 in 2026: Which File Storage Should You Use

It's the fork that decides everything else, and the three tools sit at different layers of the same stack. Object storage — AWS S3 is the definitive example, with Cloudflare R2, Backblaze B2, Google Cloud Storage, and Supabase Storage as close relatives — is the lowest level: a bucket that stores files (objects) by key, gives each one a URL, and does essentially nothing else. It's cheap, infinitely scalable, and battle-tested, but accepting an upload from a browser, securing it, putting a CDN in front, and processing images are all your job. A media platform — Cloudinary is the archetype — is storage plus a transformation and delivery pipeline built on top: you upload an image or video once and then request any variant of it through the URL (a 400px WebP, a smart-cropped thumbnail, a compressed video poster) and Cloudinary generates and caches it for you, so the platform, not your code, owns the hard media work. An upload service — UploadThing is the clearest example — is a developer-experience layer that sits above storage: it gives you a typed API, ready-made upload UI components, and server-side rules about who can upload what and how big, so you get working, secure uploads in a Next.js app without provisioning buckets or writing signed-URL logic. So the split is: S3 equals raw storage you build on; Cloudinary equals storage plus a media pipeline; UploadThing equals a batteries-included upload layer that hides the storage entirely. Many real apps combine them.

For a Next.js or React app, yes — UploadThing is built to get file uploads working faster than any of the alternatives, and that's its whole reason to exist. It comes from the same ecosystem as the modern TypeScript tooling many developers already use, and it leans hard into developer experience: you define a file router on the server that describes each upload endpoint (max size, file types, who's allowed, and what to do after upload), and you drop in prebuilt UploadButton or UploadDropzone components on the client that are already wired to it and fully typed end-to-end. There are no buckets to create, no IAM policies, no signed-URL code, no CORS wrestling — the service handles storage, the presigned upload, and delivery, and you get a clean callback on your server when a file lands so you can save its URL to your database. The catches are the usual trade-offs of a managed abstraction. You're depending on a third-party service and its pricing rather than commodity storage, so cost per gigabyte is higher than raw S3/R2 and can matter a lot at scale; you have less low-level control than owning a bucket; and while UploadThing handles storage and basic needs well, it is an upload layer, not a full media-transformation platform like Cloudinary, so heavy on-the-fly image and video processing isn't its core job. The honest summary: UploadThing is the best choice when speed of integration and Next.js developer experience matter most and your volumes are moderate; it's less ideal when you're extremely cost-sensitive at large scale or need deep media transformation.

Reach for Cloudinary when the media is the product, not an afterthought. Its superpower is on-the-fly transformation: you upload an original image or video once, and then you request any derivative of it simply by changing the URL — a specific width and height, a different crop, a format like WebP or AVIF, a quality/compression level, a blur, an overlay or watermark, or an AI-driven smart crop that keeps the subject centered. Cloudinary generates each variant on demand, caches it on a global CDN, and serves it fast, which means you never build or maintain an image-resizing pipeline, a thumbnail generator, or a format-conversion step yourself. That makes it the natural fit for image-heavy and video-heavy apps: e-commerce catalogs with dozens of product shots per item, marketplaces and social platforms with endless user-generated media, publishing sites that need responsive images at many sizes, or any product where automatic optimization directly affects page speed and conversion. It also handles video transcoding, adaptive streaming, and video thumbnails, which S3 alone does not. The trade-offs are cost and lock-in: Cloudinary's pricing is based on storage plus transformations plus bandwidth (often metered as credits), which can climb quickly on high-traffic media sites, and because your image logic lives in Cloudinary URLs and its transformation syntax, migrating away later is real work. The rule of thumb: choose Cloudinary when rich, automated image/video handling is central to the app and worth paying for; if you mostly need to store and serve files without heavy transformation, a simpler upload layer or plain object storage is cheaper and less entangling.

Use S3 or an S3-compatible store when you want the industry-standard foundation: the cheapest storage at scale, the most flexibility, the least lock-in, and a data model every developer and tool already understands. S3 is raw object storage — durable, effectively unlimited, and priced per gigabyte stored plus requests and egress bandwidth — and it's the substrate a huge portion of the internet's files sit on, including the backends of many other upload and media services. That ubiquity is the point: skills, tooling, and documentation are everywhere, and the S3 API is a de facto standard implemented by alternatives like Cloudflare R2, Backblaze B2, DigitalOcean Spaces, and MinIO, so use S3 often really means use the S3 protocol and pick the host with the pricing you want. That matters because AWS charges for egress (bandwidth out), which can dominate the bill on media-heavy apps — which is exactly why Cloudflare R2, with zero egress fees and an S3-compatible API, has become a popular choice for storing and serving large amounts of user files cheaply. The cost of all this power is that you own more plumbing: you generate presigned URLs so browsers can upload directly and securely, configure CORS and bucket policies, put a CDN (CloudFront or Cloudflare) in front for fast global delivery, and build any image processing yourself (or add a service like Cloudinary or an image CDN on top). The practical guidance: choose S3/R2 when you want cheap, standard, portable object storage and are comfortable wiring up uploads and delivery — and strongly consider R2 specifically when egress bandwidth would otherwise make S3 expensive.

The single most important security rule for file uploads is: never let the browser talk to your storage with long-lived credentials, and never route large files through your own server just to re-upload them. The pattern that solves both is the presigned (signed) URL. Your server, which holds the secret storage credentials, generates a short-lived, single-purpose URL that grants permission to upload one specific object (or download one specific file) for a few minutes; the browser then uploads the file directly to storage using that URL, and the credentials never leave the server or get exposed to the client. This keeps your keys secret, lets you enforce rules server-side before issuing the URL (is this user allowed to upload, is the file type and size acceptable, where should it be stored), and avoids your app server becoming a bottleneck for big files. With plain S3/R2 you implement this yourself with the AWS SDK's presigned-URL helpers plus CORS configuration on the bucket. UploadThing abstracts the whole dance away — your file router is exactly where you enforce the who/what/how-big rules, and the service handles the presigned upload and callback for you, which is a big part of its appeal. Cloudinary offers signed uploads and access-control features as well, so you're not exposing your account to anonymous writes. Beyond signed URLs, the same fundamentals apply across all three: validate file type and size on the server (not just the client), be cautious serving user-uploaded HTML/SVG, scan for malware if you accept arbitrary files, set sensible access controls (private by default for anything sensitive, public only where intended), and store the resulting file URL or key in your database rather than the file bytes themselves.

Cost splits along the same lines as the layers themselves, and the honest answer is it depends on your volume and your bandwidth. Raw object storage is the cheapest per gigabyte by a wide margin — S3 and its compatibles charge low storage rates plus request and egress fees — which is why storage-heavy apps gravitate to it. The trap with AWS specifically is egress: you pay for every gigabyte served out, so a media app with lots of downloads can see bandwidth, not storage, dominate the bill. That's the exact gap Cloudflare R2 targets, offering S3-compatible storage with no egress fees, which can make serving large volumes of user files dramatically cheaper; other alternatives like Backblaze B2 compete on price too. Cloudinary is priced as a media platform — a bundle of storage, transformations, and bandwidth (often expressed as credits) — so it's more expensive per unit than raw storage, but you're paying for the transformation pipeline and CDN you'd otherwise build and run yourself, which can be worth it for media-centric products and painful for high-traffic ones. UploadThing sits in between: it's a managed service priced above commodity storage because you're paying for the developer experience and the handled infrastructure, with a free tier and paid plans that are very reasonable at moderate scale but less cost-efficient than owning a bucket once you're moving serious volume. The way to think about it: for pure storage at scale, S3-compatible (especially R2 for egress-heavy workloads) wins on cost; for media transformation you'd otherwise build, Cloudinary can be worth its premium; for speed-to-ship at moderate volume, UploadThing's convenience is often worth paying for — and always model your real storage, request, and especially bandwidth numbers rather than trusting a headline price.

For a boilerplate, SaaS starter, or app you intend to hand off or sell, the guidance mirrors every other tooling decision: default to the option with the widest recognition, the cleanest integration, and the fewest strings attached for the buyer, and deviate only for a stated reason. Two defaults are defensible. If the template's selling point is fast, clean Next.js integration and a great out-of-the-box experience, UploadThing is an excellent ship — the integration is small, typed, and easy for a buyer to understand and re-point at their own account, which is exactly what you want a buyer to be able to do. If instead you want the most portable, cost-neutral, lock-in-free default, ship against the S3 API — ideally S3-compatible so the buyer can point it at AWS, Cloudflare R2, or any compatible host with only environment-variable changes; this signals a mainstream, low-risk choice and never forces the buyer onto a specific vendor's pricing. Cloudinary should ship only when the template is genuinely media-centric and the transformation pipeline is part of the value, and you should say so prominently, because a buyer expecting simple storage and inheriting a metered media bill is an unwelcome surprise. Whichever you choose, the resale rules are the same as for any code you sell: never hardcode storage credentials, access keys, or account IDs into the repo — put them in environment variables and ship an example env file; make the storage provider swappable behind a thin interface where practical so the buyer isn't married to your account; document exactly which service the app expects, how to create the equivalent bucket or app, and how to plug in their own keys; and provide sensible defaults for file-type and size limits plus signed-URL security so the buyer inherits a safe configuration, not an open write endpoint. A storage layer that's cleanly integrated, credential-free, and documented does as much to make a codebase read as production-ready as any feature you build on top of it.