The only number you really choose is the width
For a product page image, width is the one value you actually decide. Height is decided by the content, and file size follows from both. Many people work in the opposite order, agonising over the length first, then finding the width is wrong and redrawing everything.
There is a single criterion for width: how many pixels wide the destination displays it at. Make it larger and the browser scales it down, wasting file size. Make it smaller and the browser scales it up, so it looks soft.
Why 860px is the default
makeinfo's default canvas width is 860px. It is a widely used width for tall product-page images, which makes it a good place to start.
The number does not come from desktop screen sizes. Product pages are mostly read on phones, and shopping apps stretch images to the screen width. 860px is the compromise that still holds up when stretched without making the file unnecessarily heavy.
Treat it as a starting point only. If the destination specifies a width, that value wins — it differs from platform to platform, and platforms change their own rules.
If you want it sharper, raise the export scale rather than the working width. Edit at 860px and export the result at 2× (1720px). Setting the working width to 1720px means re-learning the feel of every text size and margin; raising the scale gives you exactly what you saw on screen, at twice the resolution.
dpi means nothing on the web
"Should a product page be 72dpi or 300dpi?" comes up constantly, and for an image going on the web the answer is that dpi changes nothing at all.
dpi is a note recorded in the file saying how many dots per inch to use if this is printed on paper. It is just a number stored alongside the image; it neither adds nor removes pixels. Browsers and shopping apps ignore it and look only at the pixel count. A 1000×1000 image is identical on screen whether it was saved at 72dpi or 300dpi.
So for web images, ignore dpi and look at the pixel width. For print it is the opposite — dpi determines the physical output size, so there it matters. That is a different story.
Height, and when to split
Content decides the height. But leaving it unbounded runs into three things.
- Per-image limits — many platforms cap the height or file size of a single image. Go over and the upload is simply refused.
- Loading — one very tall image has to arrive completely before anything appears. Split into several and the page starts showing from the top, which feels far faster.
- Browser image limits — once the height reaches tens of thousands of pixels, some environments fail to display it at all.
What matters when splitting is where the cut lands. Cut through the middle of a paragraph or a product photo and the small gap between pieces reads as a flaw. makeinfo's split PNG looks for empty space between blocks and cuts there. If the automatic position is not what you want, you can move the cut line yourself. Splitting a long page covers how to choose those positions in detail.
Getting the file size down
Reducing the width is the last resort when you hit a size limit. Check these first.
| Try first | Why |
|---|---|
| Splitting | If the limit is per image, splitting solves it outright, with no loss of quality at all. |
| Export scale | If you are exporting at 2×, try 1×. The file drops to roughly a quarter. |
| File format | With lots of photos, JPG is far smaller than PNG. For flat backgrounds with lots of text, PNG is both smaller and crisper. |
| Source photo size | Dropping a 4000px original into a 300px slot carries that weight into the result. makeinfo shrinks photos as they are added, but material made in another tool needs checking. |
Only after all of that should you touch the width, because width affects sharpness directly.
Dimensions people commonly use
These are widely used values. Platforms change their policies, so always check the platform's own notice or its upload screen before you publish. Treat this table as a starting point for the work, not as the final word.
| Where | Commonly used |
|---|---|
| Product page body | 860px wide. Use the platform's own width if it specifies one. |
| Main (thumbnail) image | Square, often around 1000×1000px. It appears very small in listings, so any text on it has to be large. |
| Crowdfunding story | The body width is sometimes wider than a normal product page. Check the width actually shown on the campaign editor first. |
| Social — square | 1080×1080px |
| Social — portrait | 1080×1350px (4:5). Takes up the most vertical space in a feed. |
| Social — landscape | 1200×675px (16:9) |
How to check — the image upload area of the listing form usually states the recommended size and file limit in small print. That is more often up to date than the announcements page.
Make separate images for social
Post a product page straight to social and most of it gets cropped. Feeds fold tall images, and people do not unfold them.
A promo image has to win in one frame. Keep the product shot, the name, the price and the sale dates; drop the rest. Carrying over the same colors and typefaces from the product page makes the two read as a set, so anyone who follows the link recognises the same product immediately.
In makeinfo, change the canvas width to 1080px and keep only the blocks you need. Duplicating the product page project and stripping it down beats starting over, because the colors and fonts cannot drift apart.
Before you upload
- Open it on a phone. Text that looked large on a desktop routinely turns out unreadable in the hand. Pay attention to small type like spec lines.
- Match the platform's width. Compare the number in the upload form against the actual pixel width of your exported file.
- Check the order of the pieces. They have to be uploaded in filename order for the content to run continuously.
- Keep the working file. An uploaded image is a finished product and cannot be reopened. You will certainly need to change a price or a date later, so keep a full PNG (or the zip you get when there are many photos) somewhere safe.