Resize, WebP, and compression on the way in, not on a to-do list.
A current phone camera saves a photo at 4,000 pixels wide and 3 to 4MB. The hero slot it ends up in renders 1,200 pixels and would load fine at 150KB. An image optimization API closes that gap in code: resize to the dimensions you'll actually display, convert to WebP, compress to a quality nobody can distinguish from the original, and serve the result from a CDN edge. What actually shapes your architecture is when that work runs, and there are three honest answers: on every request, in a batch you schedule, or once, at upload.
On-request transformation APIs are the famous shape: Cloudinary, imgix, ImageKit. You store one original and every variant is a URL, with width, format, and quality baked into the path, generated on first request and cached at the CDN afterward. The flexibility is real. A new crop for a redesign is a new URL, no reprocessing job, no migration. The costs are real too: transformations are metered (Cloudinary pools them into credits alongside storage and bandwidth), and every image URL in your codebase now speaks one vendor's parameter syntax. That switching cost is exactly what sends teams hunting for Cloudinary alternatives once the bill or the lock-in starts to chafe.
Standalone compression endpoints are the second shape: TinyPNG's API, Kraken.io, ShortPixel. They do one job well. You POST an image, you get smaller bytes back, you pay per image. No lock-in, no vendor URLs, but storage and delivery stay entirely your problem. They belong inside a build step or an existing pipeline; they aren't a pipeline by themselves.
Ingest-time processing is the third shape, and it flips the order of operations: the optimization runs once, when the file arrives, and what gets stored is already the set of sizes and formats you'll serve. Nothing is metered per view, no vendor syntax lives in your markup, and delivery is a cache hit because the work already happened. The tradeoff is flexibility, since your variants come from configuration rather than being conjured per request. That's the model Tonta runs, and it's the working example for the rest of this piece.
The four jobs worth doing at upload time.
Whichever shape you pick, these are the operations that earn their keep. Done at ingest, each runs exactly once per image.
Resize to real display sizes
Scaling a 12-megapixel original down to 1920px cuts the pixel count by roughly three quarters before compression even starts. Generate the widths you'll serve, a web size and a thumbnail at minimum, and stop shipping camera resolution to browsers.
Convert to WebP
Google's own study puts lossy WebP at 25 to 34 percent smaller than JPEG at equivalent visual quality, and every current browser renders it. For photographic content there's no longer a good reason to serve JPEG as the default.
Compress with intent
Quality is a dial, not a default. On Tonta it's set per uploader, so a portfolio endpoint can run quality 90 while a forum-avatar endpoint runs 70. For photos, 75 to 85 sits below the threshold most eyes can detect at normal viewing sizes.
Bake in XMP metadata
Title, description, keywords, creator, and copyright written into the file itself, so attribution travels with the image wherever it gets hotlinked or downloaded. Tonta embeds XMP via exiftool from xmp_* fields once you enable it in the dashboard.
What a typical phone photo turns into.
Representative figures for a detailed 12-megapixel outdoor photo. Flat graphics and screenshots compress far harder; your exact numbers will vary with content.
| Stage | Format | Dimensions | Typical size |
|---|---|---|---|
| Straight off the phone | JPEG | 4032x3024 | 3.5-4.5MB |
| Resized only | JPEG, quality 90 | 1920x1440 | 600-900KB |
| Resized and compressed | JPEG, quality 80 | 1920x1440 | 300-450KB |
| Resized, compressed, converted | WebP, quality 80 | 1920x1440 | 200-320KB |
| Thumbnail | WebP, quality 80 | 400x300 | 15-25KB |
No single step in that table is impressive on its own. The point is the compounding: resize, compress, and convert together turn a 4MB upload into roughly 250KB served, a cut of about 94 percent, with no visible difference in a normal page layout. Do that at upload and the expensive work is finished before the first visitor ever requests the file.
Optimize the image once, when it arrives, and every request after that is a cache hit.
How upload-time optimization looks in practice.
Tonta's integration is a single script tag pointed at a target element with an API key and a callback. It renders the uploader and POSTs multipart/form-data to Tonta's endpoint; there's no upload backend for you to write, no bucket to configure, and no processing queue to monitor. Resize, WebP conversion, and compression run server-side against that uploader's settings, and the response hands back the finished versions:
{
"success": true,
"id": "a1b2c3",
"link": "https://files.tonta.io/a1b2c3.jpg",
"versions": [
{ "label": "Web", "url": "https://files.tonta.io/a1b2c3_1920.webp",
"dimensions": "1920x1280", "format": "webp" }
]
}Those URLs serve from files.tonta.io, the CDN layer, which the homepage pegs at under 200ms edge delivery. You drop the version URL into your markup and you're done; the same decision, UI-only versus UI-plus-backend, is the fork explored in depth in our guide to picking a file upload widget. And if the upload form itself is the half you haven't built yet, the walkthrough on how to add file upload to your website covers that end to end.
Two honest limits. First, versions come from uploader configuration, so when a redesign needs a new width you update the config for files going forward rather than editing a URL parameter; if your product genuinely needs dozens of ad-hoc variants generated per request, an on-demand transformation platform like Cloudinary or imgix wins that scenario outright. Second, there are no official language SDKs today. Integration is the script tag plus plain HTTP with cURL and fetch examples, which is enough for most teams but worth knowing if yours expects a first-class client library.
On gating: resize, WebP, and compression are included on every tier, the free one included. Automatic watermarks start at Starter ($9/mo), and video transcoding starts at Professional ($29/mo), so budget for those plans if either is core to your use case.
The checklist your LCP score is graded on.
On most pages the Largest Contentful Paint element is an image. Image optimization isn't a nice-to-have for Core Web Vitals; it usually is the fix.
- Serve at display size. Shipping a 4,000px original into a 1,200px slot inflates LCP directly. The browser downloads every byte before it can paint one pixel.
- Serve WebP for photos. A quarter to a third off the transfer size at the same visual quality is the cheapest LCP win available.
- Hold quality between 75 and 85. Lower buys little extra and starts to show artifacts; higher spends bytes nobody can see.
- Deliver from an edge CDN. LCP includes the time to first byte of the image request itself. An origin server one continent away taxes every image on the page.
- Set width and height attributes. The browser reserves the space before the file arrives, which is what keeps your Cumulative Layout Shift at zero.
- Lazy-load below the fold only. loading="lazy" on offscreen images helps; on the LCP image it actively delays your score.
Is WebP always smaller than JPEG?
For photographs at equivalent quality, consistently yes, in the 25 to 34 percent range per Google's comparative study. A handful of edge cases exist (some flat graphics do better as lossless WebP or stay as SVG), but for the photo uploads that dominate real applications, WebP wins reliably enough to be the default output.
Should images be optimized in the browser before upload?
Client-side resizing is worth having because it saves upload bandwidth, especially on mobile connections. It's never sufficient, though: a request can bypass your front end entirely, so the server-side pass has to be the authoritative one. Treat browser-side optimization as a bandwidth courtesy and server-side processing as the actual pipeline.
How many image sizes should an API generate?
Fewer than you think. A full web width (1600 to 1920px), a thumbnail, and sometimes one middle size covers most layouts. Add a 2x variant only where retina sharpness is genuinely visible, like portfolio work. Every extra variant is storage and processing spent on diminishing returns.
How much does an image optimization API cost?
It depends heavily on the pricing model. Per-image compression APIs charge fractions of a cent per file. Transformation platforms meter operations, which is where surprise bills live. Upload-time platforms mostly price on storage: Tonta's free tier is $0 for 5GB and one uploader with resize, WebP, and compression included, and Starter is $9/mo for 100GB and five uploaders.
Ship images that arrive already optimized.
Tonta's free tier is 5GB and one uploader, no card required, with resize, WebP, and compression included from the first upload.