How to Handle Product Images for a Large Catalogue

A supplier sends you a spreadsheet with nine hundred rows and a folder of images named IMG_4471.jpg, final_v2.png, and scan3. Nothing lines up. You open the folder, pick a file, find the matching product, upload, rename, resize, and repeat. An hour in you've done forty. The math gets grim fast.

That's the real job in handling product images for a large catalogue: matching each file to the right product record and processing every one the same way. The uploading part is easy. The matching is where the day goes, and where the mistakes creep in.

We built an automated image pipeline for a 917-product wholesale import, so most of this comes from doing it. By the end you'll know whether your catalogue needs a pipeline or just a better afternoon.

Why hand uploading doesn't scale, even with bulk upload

Suppliers don't agree on anything. One sends JPEGs at 3000 pixels wide with the SKU in the filename. Another sends PNGs with transparent backgrounds named after the photographer's shoot date. A third sends a zip of phone photos with numbers that mean nothing to anyone outside their warehouse. You're the one who has to make all of it look like it came from the same store.

The work doesn't get easier as you go. It gets harder. The first fifty product images are fine because you still remember which supplier sent what. By the three hundredth you're cross-checking a spreadsheet for every file. By the eight hundredth you're tired, and tired people make a specific kind of mistake: the right-looking image on the wrong product. Two fittings that differ by a quarter inch. Two filters in the same housing. The person uploading image ten would have caught it. The person uploading image eight hundred doesn't.

Those mistakes don't stay quiet. A customer orders from the picture, gets something else, and now you've got a return, a refund, and a phone call. Your office manager spends twenty minutes on a problem that started as a tired click weeks earlier. And you usually find out about it one product at a time, from annoyed customers, instead of all at once.

A bulk upload tool helps you handle the product images in a large catalogue, but only with the easy half. It moves files onto the server fast. It still has no idea that scan3.jpg belongs to SKU HV-4417-B. That match has to come from somewhere, and if it comes from a human reading filenames, you've just moved the bottleneck.

The size of the catalog decides this. Forty products, do it by hand this week. Nine hundred, and hand work is the slow way to get a store full of wrong pictures.

The rules a pipeline applies for consistency and branding

A pipeline is a short list of rules, applied the same way to every file. No judgment calls, no tired clicks at image eight hundred. The rules are boring on purpose: every image named so it can be traced back to its SKU, every image the same size and shape, every image compressed before it ever reaches a product page. That last one is image optimization, and it's the difference between a catalog page that loads and one a customer abandons. Consistency is also branding — a store where every photo sits the same way on the same background looks like somebody runs it.

Name every image after its SKU, variants included

The file name is the only thing that tells you what's in the picture without opening it. So it should carry the SKU and nothing a person has to guess at. HV-4420-01.jpg, HV-4420-02.jpg. If the product has variants, the variant code goes in too, in the same spot every time, so the black one never gets filed under the chrome one.

Supplier files almost never arrive this way. You get IMG_3391.jpg, final_v2 (1).png, and three files named after a factory line nobody at your end has heard of. Renaming is the first step the pipeline does, before anything else touches the image.

Alt text comes from the same source. Build it from the product record — name, variant, SKU — and every image gets a description that matches what it actually shows. That's what search engines read, and what a customer hears if the image fails to load.

Set one size and run background removal on every file

A catalogue page looks cheap when one photo is tall, the next is square, and the product floats at a different size in each. Pick one canvas shape and one pixel size, then make every image meet it. The pipeline pads or crops to fit instead of stretching, so nothing warps.

Backgrounds get the same treatment. Pure white is the safe default for most trade catalogues, and automated background removal handles the supplier shots taken on a warehouse floor. Where lighting and shadows vary wildly between suppliers, a light normalisation pass pulls them closer together.

Then framing. The product should sit in the same spot, at the same scale, with the same margin around it, on every single page. That's what makes eight suppliers' photos read as one store, and it's the cheapest consistency and branding work you'll ever do, because the rule gets written once and applied to everything after.

Image optimization keeps your pages loading fast

Supplier photos often arrive as huge files meant for print. Drop a few hundred of those onto a category page and the page crawls, especially on a phone with one bar of signal in a customer's driveway. Slow pages lose people before they ever see a price, and that shows up in your conversion rate.

The fix is boring and automatic. The pipeline resizes each image to the largest size the site actually displays, strips the camera metadata nobody needs, and compresses the file until the savings start to show. Done right, image optimization cuts file size by a large margin with nothing a buyer would notice on screen.

It also generates the smaller versions the site serves to phones and thumbnails, so a grid of forty products isn't loading forty full-size files. Set the rule once, and every image added later follows it.

Find the products in your catalogue with no image

Some products will always come up empty. A supplier sends a folder with 900 files for 917 products. A filename has a typo, so the match fails and the file sits there unused. One image is corrupt and won't open. A few items were never photographed at all, and nobody mentioned it.

Without a check, you find out when a customer emails asking what the part looks like, or when someone in the office stumbles across a grey placeholder box on page nine of the catalog. By then it's been live for months.

The pipeline should finish by listing every product record with no image attached, and every image file that never found a product. Two lists, one run. The first tells you what to chase the supplier for. The second usually shows you where the naming went wrong, because a file that matched nothing is almost always a near-miss on the SKU.

Fix the near-misses in minutes. Chase the genuinely missing photos as a separate job. Then run the same check again after every new batch of product images, so a gap never gets more than one import old.

Match every file to a product, then run the CSV import

Handling the product images in a large catalogue is mostly reading, not uploading. Every supplier file carries some clue about which product it belongs to, and the job is pulling that clue out reliably enough to act on it.

Here's the order that works:

1. Pull everything into one folder. All suppliers, all formats, no sorting yet. Mixed file types are fine at this stage. What you want is one pile you can point a script at.
2. Read what's already in the filename. Most supplier files carry a part number, a model code or the supplier's own item number somewhere in the name, usually buried in junk characters and spaces. Some carry it in the image metadata instead. Strip the junk, keep the identifier.
3. Cross-reference against your product list. You need a lookup table: supplier code on one side, your SKU on the other. If a product has SKU variants — sizes, colors, voltages — each variant needs its own row and its own image slot, or the pipeline will attach one photo to five records and call it done.
4. Process to standard. Resize, set the background, compress, rename to the SKU. Same rules for every file, no exceptions made by hand.
5. Audit before anything goes live. Export a CSV listing SKU, matched filename, dimensions and file size. Sort by SKU and read it. Mismatches show up fast when you can see a run of similar part numbers next to their filenames.

Only after that audit do you run the CSV import that links images to product records, and only then does a bulk upload make sense. Doing the bulk upload first and checking later means you're correcting a live store while customers are looking at it.

Keep the lookup table. The next supplier batch uses the same one, variants and all.

What this looked like for a 917-product catalogue

We built this pipeline for a wholesale import. The product data was clean enough. The images were not.

They came from several suppliers, in mixed formats, at different sizes, on different backgrounds. Some filenames were the manufacturer part number. Some were the supplier's internal code. Some were the kind of name a camera gives a file. A handful of products had three images and no indication which one was meant to be the main one. Others had none.

The job was matching every file to the right record out of 917, then putting each one through the same processing. Not uploading 917 files. Matching, then processing, then checking.

So we built the lookup table first, mapping every supplier filename to a SKU, including the ones where a human had to make the call. Unmatched files went to a holding folder instead of being guessed at. Products with no image got flagged on a list before launch, not after a customer complained.

Then everything ran through the same steps: resize, normalize the background, compress, rename to the SKU, write to the import CSV. Every one of the product images in that catalog came out the same shape and the same weight class. The pages stayed fast because nothing went up at full camera resolution.

The audit CSV caught what the matching missed. A few variant SKUs had pulled the parent product's image. Easier to fix in a spreadsheet than on a live store.

Why this is a build-once job, not a subscription

An image pipeline is a piece of work with an end. You build it around the catalog you actually have: the formats your suppliers send, the naming they use, the SKU structure in your store. Once it runs clean, it's done. The script sits there. You run it again when a supplier sends a new batch.

That's a different shape of cost from software you rent by the seat every month. Monthly tools make sense for things that happen every day — scheduling, dispatch, chasing invoices. Getting nine hundred product images named and sized and matched happens when you load the catalog, and again when the catalog grows.

We think owners should own this kind of work outright. You paid for the pipeline, you keep the pipeline. Nobody raises the price on you next year because you added a person to the office.

The practical test: if the job has a finish line, buy it once. If the job repeats every single day with new data, rent the tool that handles it. Image processing for a fixed catalog has a finish line. Treat it that way when you're pricing the build.

Who keeps your image standards after launch

A pipeline holds the line only as long as somebody in the office knows the rule and enforces it. Pick that person now. Usually it's the office manager, because she's already the one opening supplier emails and adding new products.

Write the rule down somewhere she can point at. One page: the filename format tied to the SKU, the image size, the background, what gets rejected. Keep it in a shared folder next to the product spreadsheet, not in somebody's head.

New suppliers are where consistency breaks. A new vendor sends photos with their own naming, their own background, sometimes a watermark. The answer is not to make an exception "just for these." Run them through the same pipeline. If the files don't match the naming format, rename them on the way in, or ask the supplier for a file list with SKUs so the match can be made before anything gets processed.

Reshoots are the other leak. Someone photographs a product again because the first shot was bad, saves it with a new name, and now you have two images and nobody's sure which one the store is using. Rule: a reshoot replaces the original file under the original name. Same SKU, same name, new pixels.

Your product shots are branding whether you planned them that way or not. A page where every image sits at the same size on the same background reads like a company that has its act together. One odd photo in the middle of a category page stands out, and not well.

Get your product images handled once, not forever

Handling the images for a large catalogue of hundreds or thousands of products is a short, defined project. Someone writes the rules down, builds the matching and processing, runs it, and checks what came out the other side. Then it's done, and the rules stay in the pipeline instead of in somebody's head.

The work we did on the 917-product wholesale import wasn't glamorous. Supplier files came in mixed formats with filenames that meant nothing, and every one of them had to land on the right product record, sized the same, compressed, with a list at the end of anything that came up empty. That's the whole job.

If your images are a mess right now and you're staring down a bulk upload, the fix is a few weeks of build, not a monthly fee for the rest of your life.

Tell us what your catalogue looks like and book a New Project Consultation.