Bulk resize images
A catalog migration, a photo import, or a seasonal product drop rarely involves one image — it involves a folder of them, all needing the same target size. This endpoint takes the whole batch in a single call, so you're not writing a loop around a single-image endpoint and hoping your rate limit holds.
Run it online
Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.
Why batching is a different problem than resizing
Resizing one image is a solved problem; resizing three thousand is an operations problem. It means managing concurrency so you don't hammer your own infrastructure, tracking which files succeeded and which didn't, retrying failures without re-processing everything, and doing all of it without blocking whatever process kicked off the job. Teams that build this by looping over a single-image call end up rebuilding a small job queue by hand, usually under deadline pressure during a catalog migration or a site relaunch.
What one call actually does
You submit a list of source images, by URL or upload, along with one shared target size and fit mode — or per-image overrides if a subset needs different treatment — and the whole batch runs as a single asynchronous task. Internally the images are processed in parallel, and the task tracks each one individually, so a corrupted or unreachable file in the batch doesn't stall or fail the images around it. When the batch completes, the webhook delivers a manifest listing every output file alongside the status of each source image.
The scale question, answered honestly
There's no artificial cap that forces you to split a large migration into arbitrary chunks of fifty or a hundred; the practical limit is the size of the batch you submit and what makes sense for your own workflow. What we do guarantee is that pricing stays linear and transparent — the request fee is paid once for the batch, and each image is billed individually, only on success, so a ten-thousand-image migration costs exactly what ten thousand individual resizes would cost, minus nine thousand, nine hundred and ninety-nine extra request fees.
Where this sits in a real pipeline
This is the endpoint teams reach for during a one-time bulk job — migrating a product catalog to a new platform, backfilling thumbnails for an old archive, normalizing a photographer's raw delivery before publishing — rather than for steady, one-at-a-time uploads, where the single-image resize endpoint is the better fit. Because the whole batch is one task_id, it's also trivial to track progress in a dashboard or a migration script without juggling thousands of individual job identifiers.
What you can do with it
Catalog migration to a new platform
An e-commerce team moving to a new storefront resizes its entire existing product image library to the new theme's dimensions in a handful of batch calls instead of thousands of individual ones.
Backfilling thumbnails for an old archive
A media site generates missing thumbnail sizes for years of archived articles in one batch job, without touching each article's publishing workflow.
Photographer delivery normalization
A stock or events platform resizes an entire delivered shoot, sometimes hundreds of images, to its required web dimensions right after upload.
Seasonal product drop preparation
A retailer preparing a large seasonal collection batch-resizes every new product photo to the storefront's grid size before the collection page goes live.
FAQ
How many images can I resize in one batch call?
There's no arbitrary chunk limit; you submit as many source images as fit your workflow, and each one is tracked and billed individually within the batch.
Do all images in the batch have to be the same size?
No, you can set one shared target size and fit mode for the whole batch, or override the settings for individual images within the same call.
What happens if one image in the batch fails?
A failed image doesn't stop the batch; the manifest returned lists each source image's status, and only successfully resized images are billed.
Is there a free tier for the bulk image resize api?
There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.
How is bulk resizing priced?
$0.002 per batch request plus $0.005 per image actually resized, so the request fee is paid once no matter how large the batch is.
How do I get results for thousands of resized images?
The batch runs as a single asynchronous task and delivers a manifest of all output files via signed webhook, or through a signed link valid for 24 hours.
Should I use this instead of the single image resize endpoint?
Use this endpoint for bulk, one-time jobs like migrations or backfills; for steady one-at-a-time uploads, the single-image resize endpoint is simpler and just as fast.
Are batch images processed in the order I submit them?
Images are processed in parallel for speed, so completion order isn't guaranteed, but the manifest maps every output back to its original source image.
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, and soon from our app, email and Telegram.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/image/resize-batch \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"image":"https://ejemplo.com/imagen.jpg"}'const res = await fetch("https://api.kit.forhosting.com/image/resize-batch", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"image": "https://ejemplo.com/imagen.jpg"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/image/resize-batch",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"image": "https://ejemplo.com/imagen.jpg"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/image/resize-batch", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"image":"https://ejemplo.com/imagen.jpg"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"image":"https://ejemplo.com/imagen.jpg"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/image/resize-batch", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"image": "https://ejemplo.com/imagen.jpg"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "image.resize_batch",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_mb | 15 |
max_megapixels | 12 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |