I spent an hour last month staring at a marketplace listing that looked wrong. The thumbnail was stretched, the cover was soft, and the whole product page read as amateur. The problem was not the art. It was that I had guessed at image sizes instead of deciding what each render was actually for. pack_product.py in my pipeline now does this right, and the fix was mostly about understanding what 1280×720 and 600×600 each do.
The cover: 1280×720
The cover is the wide banner image. It renders at 1280×720, which is a 16:9 ratio. That ratio is what most product pages, Gumroad previews, and social cards expect. When I first built the script I rendered covers at whatever size the source files happened to be. Some came out at 2000 pixels wide, some at 800. The marketplace preview scaled them inconsistently and text in the cover looked blurry on the wide ones and cramped on the narrow ones.
The script uses Pillow to draw the cover: title, subtitle, and a price. It renders at exactly 1280×720, no scaling after the fact. Pillow's default JPEG quality is fine at that size, and the file stays small enough that a 39-product catalogue does not eat your disk. The whole 39-product run came to 856 MB of output, and the covers are a small slice of that.
One practical note: Pillow is the only third-party dependency in pack_product.py. If you are already running Pillow for asset generation, the cover render adds nothing to install. It runs fine on my 1 vCPU / 2 GB box because a single cover render at 1280×720 uses a few tens of megabytes of RAM, not gigabytes.
The thumbnail: 600×600
The thumbnail is square. It renders at 600×600 and it exists for one reason: grids. Marketplace search results, category pages, and "related products" strips are all square-cropped grids. If your only image is 16:9, the platform center-crops it and your title gets sliced off the sides.
I learned this the hard way. My first listings used the cover as the thumbnail. In grid view, the left and right thirds of the cover were cut off, which is exactly where I had put the title text. The 600×600 square render puts the title centered in the safe zone so nothing gets cropped.
600 is also small enough to load fast and large enough to look sharp on retina displays at typical grid sizes. I have not needed to go higher.
Why two images and not one
You could generate one image and let the platform scale it. The problem is that scaling is not the same as re-rendering. A 1280×720 cover scaled down to a square thumbnail loses the composition. A 600×600 square scaled up to a wide banner looks stretched. Each size is drawn for its own job, at its own dimensions, with its own layout. That is the whole point of having two renders in the script.
The script writes both into a _system folder next to where you run it, along with the product zip. You can point it elsewhere with --dir or the PACK_ROOT environment variable. The command looks like this:
python pack_product.py my-product "My Product" "A short subtitle" 9
The last argument is the price. That gets rendered on the cover so buyers see the number before they click.
What this looks like in practice
I have 1,700 assets made and 58 live on Adobe Stock. My first sale was $0.99. That is not a flex, it is just the real number. What it taught me is that packaging is not decoration. A zip with a real cover and a real thumbnail reads as a finished product. A bare file does not. The metadata CSVs, the upload tracker, the PDF renderer, and pack_product.py are the four things that turned a pile of assets into 39 finished products. The sizes in this script are a small detail, but they are the detail that made listings stop looking broken.
Where the whole thing lives
pack_product.py is one of four scripts in the digital asset factory. The other three handle the Adobe, Vecteezy, and Dreamstime metadata CSVs, the upload ledger that prevents double-posting, and the Markdown-to-PDF renderer. All four run on standard Python, two optional dependencies total, and they run on a 1 vCPU / 2 GB server with no GPU. If you want the same scripts I actually use, they are here:
Building digital products? Free guides & kits for digital product sellers.
Top comments (0)