Flipkart Product Photo Checklist: Prepare Files, Variants and the Upload Handoff

Imagine a small Indian kurti brand preparing its next Flipkart batch. The photos look finished, but the uploader has two folders called “final,” a blue variant mixed with teal, and no record of which exports were checked. This illustrative scenario is exactly what a Flipkart product photo checklist should prevent: a clean image leaving the editor without a reliable connection to the listing it belongs to.

The last handoff is a separate job from creating the image. Your catalog operator needs to know which SKU receives each file, whether the export matches current category instructions, and who cleared it for upload.

The short answer: map every image to a SKU and role, verify current category requirements, inspect the actual exported files, freeze the release package, and assign a reviewer before upload. Keep exceptions out of the ready set.

This guide covers that pre-upload handoff. “Ready” below means internally checked, not approved by Flipkart. The manifest, naming convention and release states are suggested team practices, not platform requirements.

Start the Flipkart product photo checklist with a SKU-to-image manifest

A folder tells the uploader where files live. A manifest tells them what those files mean.

Use a simple sheet with one row per seller SKU, variant and image role. If your SKU already identifies colour and size, retain those attributes as visible checks rather than asking the uploader to decode them from memory. Record the intended listing or product reference when you have one.

Useful fields include:

Seller SKU, product category and variant attributes.
Image role and intended sequence in the listing.
Source asset reference and exact final export path.
Current category-rule source and date checked.
File version, reviewer, review date and release state.

Here is a small fictional example. These roles and filenames illustrate an internal plan; they do not state Flipkart’s required image count or accepted formats.

Seller SKU	Variant	Planned role	Final export reference	State
KUR104-BLU-M	Blue, M	Main	KUR104_BLU_main_v02.ext	Ready
KUR104-BLU-M	Blue, M	Fabric detail	KUR104_BLU_detail_v01.ext	Ready
KUR104-TEAL-M	Teal, M	Main	KUR104_TEAL_main_v01.ext	Hold
KUR104-TEAL-M	Teal, M	Fabric detail	KUR104_TEAL_detail_v01.ext	Hold

Replace .ext with the format verified for your actual upload flow. Add the remaining fields as columns in your working sheet.

Notice that the teal rows are not ready simply because files exist. If their assignment or export check is unfinished, the manifest should say so. A shared photo serving several size SKUs can reference the same asset, but each assignment must remain explicit and accurate.

Check file format and size against the current category upload flow

Before preparing exports, open the current Seller Hub instructions for the product category and listing method you will use. Save a link or internal screenshot reference, the category, and the date checked. If you use a bulk template, identify that template too.

Record the answers to these questions:

Which image file types does this flow accept?
What dimensions, aspect ratio and file-size limits apply?
What presentation and image-role instructions apply to this category?
How should image references be supplied in the selected upload method?

Then check the actual delivered file, not an export preset with a reassuring name. Inspect its format, pixel dimensions and size using file information or your image application. Renaming a filename extension does not convert the image. Export again from a good master rather than repeatedly compressing an already compressed derivative.

Flipkart’s public listing guide recommends clear product images, multiple angles and accurate listing details, and explains manual and bulk listing. It is not a universal technical specification sheet. This article therefore does not invent one numerical size or format rule for every category.

Keep official instructions separate from internal preferences. “Our team prefers this crop” is not the same as “Flipkart requires it.” For background and presentation context, use the Flipkart product-image guidelines guide, then verify the current category guidance.

Match every image to the product, variant and listing data

Start with the seller SKU in the listing sheet. Follow it to the manifest row, open the referenced export, and compare it with the source photo or physical item. That direction matters: browsing a folder and guessing which listing a photograph belongs to leaves the assignment untested.

Check the commercially important attributes together:

Colour and pattern match the selected variant.
Pack quantity and included items match the offer.
Visible material, finish and construction match the product.
Main and supporting images describe the same item.
The category and listing details agree with what is pictured.

For a homeware set, a single-item listing must not inherit a photo suggesting the buyer receives the entire set. For an accessory, a detail image from a similar design is not interchangeable merely because the main photo looks right. For apparel, verify the print and sleeve details as well as the colour label.

A shared detail image may be appropriate when it truthfully represents every assigned variant. Do not assume it does. Record the shared asset deliberately and review each use.

AI-generated or edited images need the same identity check. A more polished surface is not an improvement if it changes the item being sold. If the source cannot establish an important detail, request a better capture rather than inventing one. Keep unresolved assignments on hold instead of handing the uploader a choice between plausible files.

Freeze one final export set before the handoff

Separate source masters, working edits and channel-specific finals. The uploader should receive a release folder and its manifest, not the entire editing history.

An internal naming convention such as SKU_variant_role_v01.ext can help. Use the same variant labels as the catalog sheet, and make image roles readable. This is a team convention, not a Flipkart filename rule. Confirm any actual filename constraints in your chosen upload flow.

Before freezing the set:

Reopen the final files from their delivery location.
Compare the exports with the approved source or product reference.
Check them at useful detail size and thumbnail/mobile scale.
Confirm every ready manifest row resolves to the intended file.
Move obsolete exports out of the release package without deleting source history.

A messaging-app preview is not a substitute for inspecting the delivered file. Nor is a designer’s workspace preview proof that the downloaded export is correct. Give the uploader access to the actual delivery location and check that they can open it.

Freeze the manifest alongside the files. If a file changes after review, give it a new version and return that row to review. The earlier sign-off applied to the earlier file. Tell the uploader what changed, especially if they already downloaded the package. Avoid silently replacing a signed-off asset under an unchanged filename.

Assign producer, reviewer and uploader responsibilities

You do not need a large team. You need a clear boundary between producing files, accepting them internally and using them for upload.

Producer: supplies the exports, source references and manifest entries. Flags missing information instead of quietly substituting a similar image.

Reviewer: checks SKU assignment, product truth, current-category fit and the delivered exports. Records their name and the reviewed version.

Uploader: uses only ready rows from the frozen package. Confirms receipt and raises ambiguities before substituting files or changing their order.

A one-person seller can perform all three roles, but should make separate passes. Finish editing first, review against the SKU sheet second, then upload from the checked folder. Do not make approval a memory test.

Use three plain states:

Ready: the defined internal checks are complete.
Hold: a decision or required information is missing.
Revise: a known file or assignment needs correction.

For each exception, record an owner and the next action. Release an unaffected SKU only when its own required package is complete and any shared dependency is resolved. If an upload later fails, preserve the checked version and exact feedback, then use the upload-errors guide for diagnosis.

Copy this pre-upload handoff checklist

Use this Flipkart catalog upload checklist at the release point. Complete it against the package the uploader will actually receive, not yesterday’s review copy.

Product and assignment

Each ready file is mapped to a seller SKU and intended listing.
Colour, size, pattern, pack quantity and included items agree with the offer.
Main and supporting image roles are explicit and match the current listing plan.
Shared images have been checked for every assigned variant.

Rules and exports

The category and upload method are confirmed.
Current rule source or template reference and checked date are recorded.
Actual format, dimensions and file size were checked against those instructions.
Final files reopen correctly and represent the product accurately.
Any required export change has received a fresh review.

Release and receipt

There is one identified final package with no obsolete alternatives mixed in.
Each ready row records the reviewer and exact file version.
Hold and revise rows are excluded and have named owners.
The uploader can access the manifest and final files.
The uploader has acknowledged the release version and outstanding exceptions.

If an item is unknown, do not tick it because the launch is urgent. Record what is missing and who will resolve it. A small exception queue is more useful than a blanket “all images approved” message that nobody can trace back to files.

Where Yumi fits before the handoff

Yumi belongs in the creation-and-review step, before you freeze the release package.

Start with a usable source photo. Choose a suitable scene, model, pose or output style, generate an image, compare the result with the real item, and download the selected output. Then perform the seller-side export checks and SKU mapping described above.

The Yumi Flipkart product-image workflow explains that sequence and keeps product accuracy and current category checks with your team. The broader AI product photo generator overview covers the same create-and-review approach beyond one marketplace.

Do not mistake image generation for catalog release management. This workflow does not establish that Yumi uploads listings, maintains your manifest, validates platform compliance or secures approval. Those remain separate responsibilities.

If the source image hides the product shape, cannot resolve a finish, or misrepresents the colour, recapture may be the right next step. Professional photography remains appropriate when new capture or bespoke art direction is needed. Review the actual output, not the promise of automation. You can also browse product examples before deciding which source photo to test.

Frequently asked questions

What should a Flipkart product photo checklist include before upload?

Include seller SKU and variant mapping, image roles, current category instructions, actual export checks, file versions and named sign-off. Add an exception owner and uploader receipt. A folder of images is not enough if the uploader cannot identify the checked file for each listing.

What file format and image size should I use for Flipkart?

Use the current instructions for your category and upload method in Seller Hub. Check accepted formats, pixel dimensions, aspect ratio and file-size limits before export. This guide does not supply universal numerical requirements. Renaming an extension is not a valid format conversion.

How do I stop photos being assigned to the wrong colour variant?

Map each image explicitly to its SKU and colour in the manifest. Compare the referenced final file with the source or physical product, then check the listing’s variant field. Filenames help, but do not prove that the image inside is the correct colour.

Can I reuse the same export on Flipkart and other marketplaces?

Only after checking that it fits each destination’s current requirements and listing context. Keep reusable source masters separate from channel exports. The one-source, multiple-marketplaces workflow explains how to organise that adaptation without assuming every final file is interchangeable.

Does an internally approved image batch guarantee Flipkart approval?

No. Internal sign-off means your team’s stated checks are complete for the identified files. Flipkart makes its own image and listing decisions. Keep internal readiness separate from upload submission, marketplace review and publication status.

What if an image still fails after these checks?

Keep the exact submitted file, SKU reference and platform feedback. Diagnose the failure before regenerating everything. Use the Flipkart seller image upload-errors guide to separate export problems, assignment issues and later review feedback. Change only what the evidence supports.

Prepare one checked package, not another “final” folder

The handoff is finished when the uploader knows which file belongs to each listing, which version was checked, and which exceptions must wait. That discipline is useful whether your images came from a phone, a studio or an AI-assisted workflow.

Test one real product photo with Yumi, compare the output with the item, and prepare the selected file for your Flipkart handoff. Keep the final decision tied to the product and the listing, not just a better-looking preview.