How to Generate Website Thumbnails for an Indian Handicrafts Seller Directory

Generate thumbnail files from each seller’s original photograph, sized and cropped for the directory’s actual card layouts. Keep the original, make responsive variants, and check that the crop still shows the craft’s defining details at card size. Use descriptive filenames and useful alt text. There is no single required thumbnail dimension or format for every directory; your design, delivery stack, and image content determine the right choices.

This guide covers seller profile photos, individual handicraft listings, or both. The same process applies to each, but the subject and alt text should match the image: a seller portrait needs different cropping and description from a close-up of a handwoven textile.

1. Decide what the card needs

Start with the directory design, not an arbitrary image specification. Record the card’s visible aspect ratio and the widths at which cards appear on mobile, tablet, and desktop. A square seller avatar, a landscape product card, and a tall craft detail image need different crops.

Choose a display ratio. Use the ratio your card actually renders, such as 1:1 or 4:3. Keep it consistent within a list so the page does not jump between cards.
Choose responsive widths. Determine the rendered image width at each layout breakpoint. Generate enough sizes to avoid serving a huge original to a small card without creating many nearly identical files.
Choose a focal point. Keep the whole item or its defining detail visible. For a pot, that may include the rim and painted surface; for embroidery, it may be the stitched pattern. Do not crop all images mechanically around the center if the subject is off-center.
Retain a high-quality original. Store the seller’s source separately from generated variants so you can recrop or regenerate later.

Do not stretch an image to fit a ratio. Crop it intentionally, or use a neutral background or letterboxing where showing the complete object matters more than filling the card.

2. Build an upload-to-thumbnail workflow

Accept and validate the source. Check that the upload is an allowed image type, can be decoded, and is within your application’s file and pixel limits. Reject corrupt files and handle unusually large dimensions before processing.
Keep the original. Store it separately from thumbnails. Use a stable seller or listing identifier in storage metadata rather than relying on a seller-supplied filename for uniqueness.
Apply orientation. Some photos contain orientation metadata. Normalize the image orientation before calculating the crop, or a correctly framed photo can appear rotated.
Crop for each card variant. Use a focal point or a crop preview when possible. For seller portraits, avoid cutting off faces; for craft products, preserve the material, shape, and distinctive workmanship.
Resize to the chosen output dimensions. Do not upscale a small source and imply that it has gained detail. If the source is too small for the card, request a better upload or serve it with an appropriate quality expectation.
Encode and inspect. Generate a suitable format, then inspect representative outputs at their actual display size. Tune quality against visible texture and file size.
Publish variants and metadata. Use stable URLs or versioned filenames so refreshed images do not remain hidden behind stale browser or CDN caches.

For a small directory, generate variants when a seller uploads or updates an image. This makes the files ready when a visitor opens a listing. For a large or changing catalog, an image delivery service or CDN may resize on demand. Compare these approaches based on crop control, format support, responsive delivery, integration effort, and operational cost; the right choice depends on the existing stack.

3. Choose formats and compression

Choose by the image’s appearance, the formats your delivery path supports, and the payload size. JPEG is a familiar choice for photographs. WebP or AVIF can be useful where your image pipeline and destination support them. PNG is useful when lossless detail or transparency is needed, though it may produce a larger file for an ordinary photograph. There is no universally best format for every craft image.

Make each file’s extension match its actual encoding. Google Search Central lists BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF as formats it supports for images referenced by an img element’s src; that is Google Search support, not a guarantee that every browser or delivery system supports every format. Google also recommends image optimization and responsive techniques. Google Search Central: Image SEO best practices.

Compression is a visual decision. Compare outputs at the card’s real display size, paying particular attention to woven texture, fine carving, glaze, and embroidery. A file that is small but makes the craft indistinct is a poor thumbnail. Keep a fallback in the markup when serving newer formats through picture, and ensure the fallback is a useful image.

4. Serve responsive thumbnails in HTML

Use srcset and sizes so the browser can select a suitable generated width. The following example assumes a card that can be about 280 CSS pixels wide on a narrow screen and about 360 pixels in a two-column layout. Adjust both values to match your actual CSS. The files shown are examples of your generated variants, not a required naming scheme.

<img
  src="/images/craft-842-640.webp"
  srcset="/images/craft-842-320.webp 320w,
          /images/craft-842-640.webp 640w,
          /images/craft-842-960.webp 960w"
  sizes="(max-width: 640px) 280px, 360px"
  width="640"
  height="480"
  alt="Blue glazed ceramic bowl with a carved geometric rim"
  loading="lazy"
  decoding="async">

The width and height attributes describe the selected image’s aspect ratio and help reserve space while it loads. Set them to match your layout ratio and generated files. Lazy-load images below the initial viewport; avoid lazy-loading an image that is important to the initial visible content.

If you provide AVIF or WebP plus a JPEG fallback, use picture. The final img remains the fallback and should have meaningful alt text.

<picture>
  <source
    type="image/avif"
    srcset="/images/craft-842-320.avif 320w,
            /images/craft-842-640.avif 640w"
    sizes="(max-width: 640px) 280px, 360px">
  <source
    type="image/webp"
    srcset="/images/craft-842-320.webp 320w,
            /images/craft-842-640.webp 640w"
    sizes="(max-width: 640px) 280px, 360px">
  <img
    src="/images/craft-842-640.jpg"
    srcset="/images/craft-842-320.jpg 320w,
            /images/craft-842-640.jpg 640w"
    sizes="(max-width: 640px) 280px, 360px"
    width="640"
    height="480"
    alt="Blue glazed ceramic bowl with a carved geometric rim"
    loading="lazy"
    decoding="async">
</picture>

5. Name images and write alt text accurately

Use a short, descriptive filename that identifies the visible subject, for example blue-glazed-carved-ceramic-bowl.webp. Avoid opaque upload names in public URLs where practical, and avoid stuffing unrelated search phrases into filenames.

Alt text should describe what is actually visible and should fit the image’s context. Do not infer the maker’s location, community, material, or technique from appearance alone. If a seller’s profile image is decorative or redundant with adjacent text, the appropriate alt text may differ from a product image’s description. Google recommends descriptive filenames and relevant image context; its guidance also emphasizes clear, high-quality images. Google Search Central image guidance.

6. Check directory-specific image requirements

Google Merchant Center requirements apply when submitting product data to Merchant Center; they are not universal rules for thumbnails on your directory. Its current help page gives a 500 × 500 pixel minimum for product images, a recommendation of around 1500 × 1500 pixels or above for listing formats, a 64-megapixel maximum, and a 16 MB file-size maximum. It also says the minimum becomes 500 × 500 for all products beginning January 31, 2027. Apply those constraints only if your images are being submitted to Merchant Center, and verify the current guidance when implementing a feed. Google Merchant Center: Image link.

Platform behavior is also specific to that platform. For example, Shopify says its CDN automatically compresses JPG images and often serves WebP. Do not assume another host or a custom directory pipeline does the same. Shopify: Image SEO guide.

7. Test the result on real cards

Check mobile and desktop card layouts and confirm the crop does not hide important details.
Inspect a range of subjects: portrait, wide object, tall object, fine texture, bright background, and dark background.
Confirm every responsive URL loads and returns the format named by its extension.
Check that image dimensions reserve the correct layout space and that lazy loading does not delay prominent content.
Review alt text against the actual image and seller-provided facts.
Replace an image and confirm cache invalidation or versioned URLs serve the new thumbnail.

8. Troubleshooting

Problem	Likely cause	Fix
The thumbnail looks soft or pixelated	The selected variant is smaller than its rendered size, the source is low resolution, or compression is too aggressive.	Generate a suitable larger variant from the original, reduce compression, and inspect at the actual card size. Do not upscale a tiny source expecting new detail.
The craft is cut off	A fixed center crop does not match the subject’s position or shape.	Store a focal point or use a crop preview; adjust the crop for that image. Use contain or letterboxing when the whole item must remain visible.
Images appear stretched	The image is forced into the card dimensions without a crop or preserved ratio.	Use a deliberate crop or preserve aspect ratio with a background. Keep the source and output dimensions consistent with the chosen strategy.
The wrong responsive size loads	`sizes` does not reflect the card’s CSS width, or a `srcset` URL is missing.	Match `sizes` to the real layout and test every listed URL. Keep width descriptors consistent with actual file widths.
A browser cannot display a variant	The file extension does not match the encoded format, or the client/delivery path does not support that format.	Verify the encoding and response content type, correct the extension, and provide a compatible `img` fallback.
A newly uploaded thumbnail does not appear	A browser or CDN cache still holds the old URL.	Use content-versioned filenames or invalidate the relevant cache after regeneration.
Uploads fail only for some photos	The file may be corrupt, unusually large, encoded in an unsupported format, or have orientation metadata your pipeline does not handle.	Validate and decode uploads, enforce reasonable size and pixel limits, normalize orientation, and report a clear upload error so the seller can provide another file.
The listing image description is inaccurate	Alt text was inferred from appearance or copied from a generic keyword template.	Describe only visible details and facts confirmed by the seller; use concise, image-specific text.

9. Performance, reliability, and cost

Smaller, correctly sized files reduce the amount of image data a directory sends, while responsive delivery prevents a small card from downloading the original unnecessarily. The practical savings depend on source photos, selected dimensions, encoding, caching, and traffic; there is no single performance figure that applies to every directory.

Generate variants once and reuse them. A deterministic variant key based on the source version, crop, width, and encoding can prevent duplicate work. Keep originals and make generation failures observable: a failed thumbnail should be retried or shown with a clear placeholder rather than leaving a broken card. If variants are generated on demand, account for first-request processing time and ensure concurrent requests do not trigger duplicate conversions.

Cost depends on where processing happens. A self-managed upload pipeline uses application or worker resources and storage for each variant. An image CDN may charge according to its own delivery, transformation, or storage model; check its current terms and estimate from your directory’s volume. Keeping only the variants you actually serve avoids needless storage, while retaining the original protects future recropping options.

Or skip the browser setup

For a rendered directory page or a seller listing, ScreenshotNeo is a website screenshot API and MCP server. It returns an image or PDF from one GET request and can capture a page for a visual review of card crops and layout. It does not generate optimized thumbnail files from seller uploads; use the image workflow above for production thumbnails.

cURL:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com/sellers \
  -o directory-review.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com/sellers"},
    timeout=90,
)
r.raise_for_status()
open("directory-review.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/sellers'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('directory-review.webp', bytes));

See the ScreenshotNeo API documentation for request options. Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000 screenshots. Sign up for free ScreenshotNeo access.

FAQ

Should directory cards show the seller or a product?

Use the image that helps a visitor understand that specific card. Seller profile cards can use a portrait or representative workshop image; product listings should show the listed object. Keep the alt text aligned with the image and surrounding content.

Do all thumbnails need the same dimensions?

They should share a consistent displayed ratio within the same card layout, but you can generate several widths for responsive use. Different card types can use different ratios.

Is Merchant Center’s 500 × 500 minimum required for my directory?

No. It is guidance for Merchant Center product image submissions, not a general directory-thumbnail requirement.

Can I use one original image for every card size?

You can, but it may make visitors download more data than the displayed card needs. Generated responsive variants let the browser choose a more appropriate file.