Miko Bulk Image Resizer
Rewriting a live catalogue without breaking it
Miko Bulk Image Resizer is the eighth app in our own Shopify suite. Editing tens of thousands of images that a storefront is actively serving turned out to be a problem about references, colour and billing integrity, far more than about resizing. This is the build note.
Modes, settings and pricing live on the Miko product page. Installing costs nothing, the first 100 images are included, then it is $0.10 per image actually resized.
The job merchants kept asking us to do by hand
On theme and Plus projects we kept meeting the same drag on page speed: a catalogue of photos from three or four different sources, none of them sized for a shop page. The usual fix is somebody exporting a folder, running it through a desktop tool and uploading it again, which costs a day, loses alt text, and often breaks which picture belongs to which variant.
Before writing a line we read the one-star reviews on the tools already doing this. The complaints were consistent and specific: colours came back wrong, images were cropped badly, and there was no way to undo a run once the storefront looked broken. Those three became the spec, and they are the reason the app is built the way it is.
Six decisions that are not in any feature list
Each of these is a failure we designed out on purpose, and most of them only show up at catalogue scale.
Colour is the whole reputation
The image library everyone uses defaults to discarding metadata, which throws away the colour profile. Feed it a wide-gamut or print-space photo and the result comes back visibly wrong, which is precisely the complaint on competing tools. Every one of our pipelines ends by converting to standard sRGB and writing that profile back explicitly, so a photo that looked right in the studio still looks right on the product page.
Replacing a file breaks what points at it
On Shopify an image is not a file you overwrite, it is a media record other things reference. The swap is therefore staged upload, create, poll until the new media reports ready, move it into the original position, and only then remove the old one. If it never reports ready we keep both rather than delete an original whose replacement is unconfirmed, and any variant attached to that image is re-pointed at the new media so no variant quietly loses its picture.
Metered billing has to be exactly right
Charging per image means a retry can become a second charge. A scan that dies mid-page resumes from its last cursor and can legitimately re-read the same page, so the item table carries a uniqueness constraint and duplicate rows are dropped rather than created. Each slice sends one idempotency key, included credit is deducted before any early return rather than at the end, and images that were skipped or failed are never billed at all.
The bottleneck was the network, not the pixels
Each image is a download, a transform, a staged upload and a wait for processing, so the process spends nearly all its time idle. Run one at a time it measured around 0.6 images a second, which is roughly nine hours for a twenty thousand image catalogue. Slices now overlap several images at once while the transform itself is pinned to a single thread, and input is capped at 256 megapixels so one accidental decompression bomb cannot take down every other store's run with it.
A preview that cannot lie
Nobody should approve a bulk change from a description. The preview runs real photos from the store through the identical pipeline the run will use, and the numbers shown are measured on the full size output while only the picture on screen is scaled down. The preview is also tied to the exact settings that produced it and is thrown away the moment a field changes, so a stale before and after can never be the thing a merchant approves.
Undo, or it is not really safe
Every original is copied to persistent storage before it is replaced and kept for 30 days, restorable for a whole run or for one image. Restoring is itself a queued background job rather than a request that has to finish before the tab closes, and expired backups are swept and marked as expired in the interface, so the app never offers a restore it cannot actually perform.
Bulk work on a live store, done carefully
Most private app and migration briefs are a version of this one. Something has to be changed across an entire catalogue, on a store that is taking orders while it happens, and it has to be reversible. That means resumable background jobs, a preview before commitment, references that stay intact after a record is replaced, and billing or throughput limits the client controls rather than discovers. Those are the parts we had to get right here, and they transfer directly.
What the app does, in short
- Resizes, compresses, converts and watermarks product and collection images in place, with nothing to download
- Five resize modes, three fit styles, and a quality and format choice on top of any of them
- Keeps colour as standard sRGB and keeps variant images attached to their variants
- A free catalogue health read, and bulk alt text from a template, neither of which is ever charged
- Scheduled and automatic runs, a spending limit the merchant sets, and 30 days of undo per run or per image
Full detail, every mode and the pricing are on the Miko Bulk Image Resizer product page, and the merchant guide is at miko.co.nz/image-resizer-docs.
Two screens that carry the safety argument
When software is about to change thousands of things at once, the interface work is mostly about consent and reversal.
The preview stage. Real photos, the real pipeline, and figures measured on the full size result rather than on the thumbnail being displayed.
The history view. Reversal was designed in from the first commit rather than added after somebody needed it.
Questions we get about this build
Tripster Developers, a Shopify agency in Auckland, New Zealand. We wrote the image pipeline, the Shopify media swap, the backup and restore system and the usage billing, and we run the app in production ourselves.
On the product page at miko.co.nz/image-resizer, which carries every mode, setting and screen, plus the pricing. This page is the build note that sits behind it.
Not yet. It is in review with Shopify. The merchant guide is already published, so the whole app can be read through before the listing goes live.
Replacing a live image without breaking anything that points at it. Shopify media is created, polled until ready, reordered into the original position and only then is the old file removed, and variants are re-pointed at the new media so no variant loses its picture.
Yes. Bulk operations over a large catalogue, resumable background work, metered billing and an undo path are common requirements in private app and integration work, and they are all in production here. See Shopify app development.
Built by Tripster Developers
Miko Bulk Image Resizer is built and maintained by Tripster Developers, a certified Shopify Plus Partner working on Shopify since 2016, from Auckland, New Zealand. Bulk Image Resizer is the eighth app in the Miko suite, built for merchants carrying more image weight than their storefront can afford.
We build the same way for clients: custom Shopify themes, Shopify Plus builds, ERP and middleware integrations, and private apps for merchants who need something the App Store does not sell.
Something to change across your whole catalogue?
Tell us what needs to move, and we will tell you how we would do it safely.
Start a conversation