S3 is the default storage primitive on AWS, but it's just storage — there's no built-in image hosting page, no variants, no on-the-fly resize, and AWS charges egress on every byte delivered. swiftimg gives you that whole layer (hosting, variants, transforms, signed URLs, hosted viewer page, delivery) with flat pricing and no delivery overage.
swiftimg vs Amazon S3 at a glance
| Feature | swiftimg | Amazon S3 |
|---|---|---|
| Egress fees | None | Per-GB to internet |
| On-the-fly resize / WebP | Built in | Build it yourself (Lambda@Edge, etc.) |
| Hosted viewer + share page | Yes | No |
| Signed URLs | Built in (HMAC) | Yes (presigned) |
| Free, no-account uploads | Yes | No |
| Setup | Upload and go | Bucket + IAM + CloudFront + Lambda |
| Pricing model | Flat plan + overage | Storage + requests + egress |
List prices as of 2026 for context — directional, not apples-to-apples. Check each provider for current pricing.
When Amazon S3 is the better choice
S3 if you already have IAM, lifecycle policies, and a CloudFront pipeline standardised on AWS, or if you need raw object storage you'll build a custom image stack on top of.
swiftimg vs Amazon S3 — FAQ
Can I keep using S3 for the original and swiftimg for delivery?
Not directly — swiftimg is the origin. The simpler move is to push images into swiftimg via the REST API and let it handle storage and delivery.
What about CloudFront on top of S3?
That's the typical AWS recipe and it works, but you still maintain the variant pipeline yourself and pay CloudFront egress. swiftimg includes the variant pipeline and the CDN.
Will URLs survive migration off swiftimg?
Yes — direct image URLs use stable IDs. If you ever leave, you can fetch each /originals/<id> via the API and re-host.
Ready to switch from Amazon S3?
Start free, then unlock the full API, transforms, signed URLs, and a custom domain on the Developer plan.