Ask your website provider to deliver food photos in WebP or AVIF, with a JPEG fallback where needed, and to serve image dimensions that fit the visitor’s screen. For graphics that need transparency, ask whether WebP or PNG is appropriate. Keep the original files, too.
There is no single best pixel size for every image. A wide homepage banner needs a different file from a small menu thumbnail. Give your provider a short specification for each use, then check the actual site on a phone before approving it.
Inventory your images and permission to use them
Start with a list of the images already intended for the site and where each will appear: homepage banner, menu item, dining room photo, logo, or icon. This is a file-delivery exercise, not a request to pick new dishes to photograph.
For each image, record who supplied it, where the original is stored, its pixel dimensions, and whether you have permission to use it on your website. A file downloaded from an old site or social account may be much smaller than the original. It may also be cropped or compressed already, so it is a poor starting point for a large banner.
Ask your photographer or designer for the highest-quality originals they can provide, along with any agreed limits on use. Confirm whether you may resize, crop, and convert them for the website. Keep those answers and the files in a folder the restaurant can access. If ownership or usage terms are unclear, ask the creator and, where necessary, a qualified adviser.
Separate originals from web-ready copies. Name the copies by purpose, such as homepage-banner-wide and menu-soup-small, rather than replacing the original. Include the business name only if it helps your team identify files; descriptive names are more useful than a string of unrelated search terms.
Also identify who can make changes after launch. Can a manager replace an image without asking the provider? Will the system resize an upload, or must the manager prepare several files? The answer affects how much ongoing work the restaurant takes on.
Choose formats and dimensions by use
WebP and AVIF are good formats to request for photographic images because they can offer smaller files at acceptable visual quality. Results vary by image and compression setting, so ask to see the finished files rather than assuming one format always wins. JPEG remains a useful fallback for photos when a visitor’s browser or another part of the site cannot use the preferred format.
PNG can be useful for a logo or graphic that needs transparency and crisp edges. It is often a less efficient choice for a large food photograph. Ask the provider to preserve a logo’s transparency and check its edges at the size visitors actually see.
The table below is a starting specification, not a universal limit. The pixel dimensions describe candidate files, not a requirement to stretch every source image. The provider should adjust them to the site’s actual layout and screen needs.
| Use | Starting dimensions | Format and check |
|---|---|---|
| Wide homepage banner | About 1600 pixels wide for a large display; a smaller mobile version where useful | WebP or AVIF; JPEG fallback if needed. Check the crop on a phone. |
| Menu item photo | About 600 pixels wide for a medium display; smaller versions for thumbnails | WebP or AVIF; JPEG fallback if needed. Check detail at the displayed size. |
| Logo with transparency | Enough pixels for the largest displayed logo without stretching | WebP or PNG. Check transparency and sharp edges against the site background. |
| Small decorative graphic | Match the largest intended display size, allowing for sharp screens | Choose a supported format; check that the graphic remains legible. |
Ask the provider how the site selects an appropriately sized file for each screen. A responsive image setup can offer several widths and let the browser choose. Displaying a large file in a small box does not necessarily make the download small.
Also ask about high-density screens. An image displayed 300 pixels wide may benefit from a wider source on a sharp phone screen. That does not mean every thumbnail needs the same large file as the homepage banner. If the available original is too small, request a different crop or use a smaller display area rather than enlarging it until it looks blurry.
Set a delivery specification and test compression
Put the following requirements in writing when requesting a quote or reviewing a build:
- Keep the restaurant’s originals separate from the web-ready files and make both accessible to the restaurant.
- For each image, identify its use, crop, preferred format, fallback where needed, and intended display sizes.
- Provide responsive widths for large photos and menu images instead of sending the same oversized file to every screen.
- Compress photos to reduce file size while keeping food, text, and edges clear at their displayed size.
- Confirm how replacement uploads are handled and whether staff can change images themselves.
- Check that essential images load and that alternatives are available when a preferred format cannot be displayed.
Compression reduces the amount of data in a file, but aggressive compression can make a photo look muddy or introduce visible artifacts. Ask for a side-by-side comparison at the actual display size. Zooming far beyond that size can reveal flaws visitors may never see; checking only a tiny preview can hide flaws they will see.
Hypothetical example: A restaurant has an original banner that is 3000 pixels wide. Its provider prepares a 1600-pixel-wide desktop candidate and an 800-pixel-wide mobile candidate. The mobile file is 140 KB, while a more heavily compressed version of the same dimensions is 85 KB. On a phone, the smaller file makes garnish and lettering look smeared; the 140 KB version looks acceptable. The owner chooses the latter as the better balance for that image.
Those figures are assumptions, not targets every restaurant should meet. They cover the individual image files only, not the rest of the page, hosting, provider labor, or other operating costs. A different crop or photograph could produce a different result. If the mobile layout uses a narrow slice of the wide image, ask for a deliberate mobile crop rather than letting the site cut off an important part automatically.
Before comparing providers, ask whether preparing responsive versions and later image replacements are included in the quote. Request separate amounts for initial preparation and any ongoing or exception work, such as recropping a supplied file. That makes the operational quote easier to compare without treating image file size as a measure of cost.
Check the finished page on mobile
Review the actual page, not just a folder of exported files. Open the homepage and a menu page on a phone. Check that the banner’s subject is visible, the logo is sharp, and menu images do not look stretched. Turn the phone or change the browser width if the layout supports it, and look for awkward crops or images that cover buttons and text.
For a simple loading check, use a browser’s developer tools or ask the provider for a screen recording showing a simulated slower mobile connection. Inspect which image file is requested and its transferred size. A simulation is a practice check, not proof of how every guest’s connection will perform. Repeat the visual check on an actual phone and connection when possible.
Use clear acceptance criteria. For example, approve a banner only when its main subject remains visible in both the phone and desktop layouts, the displayed image is not visibly smeared, and the page loads a file intended for that screen size. Ask the provider to explain any exception, such as a small original that cannot support the desired banner width.
Finally, replace one noncritical image as a practice task before launch. Confirm that the manager can find the control, upload a permitted file, preview the crop, and restore the prior image if needed. Do this in a preview or staging area where available; agree on who can publish the change. This check does not require a payment, guest message, or courier dispatch.
If you are also comparing editing and ownership terms, use the restaurant website builder comparison and the guide to who owns your restaurant website domain. If the site connects to online ordering, check image changes on the ordering journey as well as the homepage.
Next step: Send the specification above to your current provider with one banner, one menu image, and your logo. Ask for the intended formats, responsive sizes, fallback, and a mobile preview. You can also ask Fleksa about its restaurant website and confirm current US availability and image setup for your needs.
Frequently asked questions
Should every restaurant photo be a WebP or AVIF file?
Not necessarily. Either can be a useful preferred format for photos, but ask for a compatible fallback where needed and compare visible quality at the intended size. Keep the original regardless of the web format.
What size should a menu image be?
Start by asking for a version around 600 pixels wide for a medium display, plus a smaller thumbnail where appropriate. The right dimensions depend on the layout and screen; check that the site does not send a banner-sized file for a tiny thumbnail.
Can I upload one large original and let the website handle it?
Possibly, but confirm how your provider processes uploads. Ask whether it creates responsive sizes, which formats it serves, and how you can preview the crop. Keep your own original even if the site stores a copy.
