A restaurant can have excellent photography and still end up with a chaotic delivery menu. One dish is tightly cropped, another has a wide plate and tiny food, a third looks gray after compression, and the hero image takes several seconds to appear on mobile data. Customers do not see the carefully art-directed Figma file. They see a grid of small, fast-loading choices.
TinyImage can export and compress the image set from Figma. The useful workflow begins earlier: define each channel’s slots, create honest crop rules, and review the exported images at the size and connection where people will order.
Start with the menu, not the photo library
Make an inventory of every image placement before preparing files. A typical package might include category headers, square dish thumbnails, wide featured-item cards, bundle promotions, and a restaurant cover image. Record the required dimensions, format, file-size limit, naming rule, safe area, and whether the platform crops uploaded files again.
Do not assume that one large square can serve every slot. A bowl photographed from above may survive several crops; a tall drink beside a narrow plate may not. Treat the channels as separate compositions that share one approved source image.
Build a representative test group before processing the full menu:
- pale food on a white plate;
- dark food with subtle texture;
- a platter with several important items;
- a tall product such as a bottle or cup;
- a dish with garnish near the edge;
- an item with no approved photography.
This small group reveals crop and compression problems much faster than reviewing 150 near-identical exports.
Set crop rules customers can trust
Food photography is product information. A crop should make the dish legible without making the portion look larger or hiding an included item. Keep the main food inside a shared safe area, use a consistent camera scale within each category, and preserve meaningful context such as side dishes or packaging when it affects the purchase.
Avoid solving every awkward source with extreme zoom. If an important item cannot fit the slot, flag the source for a new photograph or use a documented fallback treatment. Never stretch an image to fill a different aspect ratio.
In Figma, arrange frames by channel and slot rather than by photographer filename. Put the menu item ID, market, placement, and revision in the layer or frame name. That makes the export package traceable when an aggregator rejects one image or a price-and-menu update introduces a new dish.
Choose formats by image behavior
For photographic menu images, a compressed photographic format normally gives a better size-to-quality result than PNG. Transparent logos and simple graphic badges may still need PNG. If the ordering site supports modern formats, compare WebP or AVIF with a conventional fallback instead of assuming the newest format is accepted everywhere.
The WebP versus AVIF guide for Figma exports explains the broader tradeoff. Delivery marketplaces can impose their own upload rules, so their current specification remains the authority.
Use TinyImage to export the approved frames and compress them toward the documented budget. Keep compression settings consistent for comparable images, but allow exceptions: steam, fine herbs, noodles, and textured fried food can show artifacts sooner than flat backgrounds.
Review at ordering size
A full-screen image can hide problems that are obvious in a 96-pixel menu tile. Review the files in three ways:
- At 100% to find halos, block artifacts, banding, or over-sharpening.
- At the actual rendered card size to judge food recognition and crop balance.
- In a realistic menu grid to check consistency across adjacent dishes.
Compare the compressed output with the approved Figma frame, not only with another compressed version. Check color and contrast on more than one display. A technically small file is not a win if sauce texture disappears or pale ingredients merge into the plate.
Also inspect filenames, dimensions, orientation, and embedded transparency. Open the actual exported file rather than trusting the thumbnail in a file browser.
Pilot the real upload path
Upload the test group to a staging menu or low-risk channel first. Some platforms recompress, crop, or convert images after upload. Verify the final customer-facing result on a phone, using a typical mobile connection, and check both list and detail views.
Measure more than whether the upload succeeded:
- Does the first menu screen become usable quickly?
- Does the platform apply an unexpected center crop?
- Are light and dark dishes equally clear?
- Do unavailable-image fallbacks look deliberate?
- Can operations match every published image to a menu item ID?
The ecommerce product image workflow covers catalog imagery more broadly. Food delivery adds perishability, portion expectations, frequent menu changes, and very small decision-making thumbnails.
Handoff a package operations can maintain
Deliver the final files with a manifest containing menu item ID, public item name, placement, dimensions, format, file size, source frame, approval status, and destination channel. Separate current files from retired items so an old seasonal dish is not accidentally restored.
When a dish changes, update the source frame and regenerate every required placement from the same approved state. Do not let restaurant operations make one-off crops in each platform unless those changes are recorded back in the source.
Before publishing the full set, confirm that every crop represents the item honestly, required details remain visible, files meet channel limits, naming maps to the menu system, and a pilot upload survives the platform’s own processing. TinyImage removes repetitive export and compression work; the team still owns accurate merchandising and final-channel review.
Read as Markdown Related resource index Site index for AI agents
Pro Bundle