BlogImage Compression

How to Compress Restaurant Menu Images for Websites

Q: Will compressing a menu image make the text unreadable?

It can if you reduce quality too aggressively or downscale below the intended display size. Work from the largest dimension the layout actually uses, choose a starting quality, then zoom to 100% on a real device and check the smallest prices, allergen notes, and footnotes before finalizing.

Q: Is PNG better than WebP for a text-heavy menu?

Lossless WebP or PNG both preserve text without compression artifacts, but at the cost of larger files. Try lossless WebP first: it is lossless and typically smaller than PNG. Reserve lossy WebP or AVIF for photographic menus where some quality reduction is acceptable, and always verify text legibility after compressing.

Q: Can I publish a PDF menu instead of an image?

A PDF is better than a single large image for text accessibility, because it can contain selectable text. However, a PDF embedded in an iframe or linked as a download does not render as well on mobile as a dedicated HTML or image-based menu, and it may not contribute to page performance signals in the same way. Prefer HTML or a well-optimized image with an accompanying HTML text menu.

Q: How do I test whether a compressed menu is still readable?

Open the compressed file at 100% zoom on a real phone or use browser DevTools at the smallest viewport you support. Look specifically at the smallest printed prices, allergen codes, footnotes, and any low-contrast text. If any are blurry or ambiguous, raise the quality setting or use a lossless format for that file.

Learn how to compress restaurant menu images without blurring prices: choose WebP or AVIF, resize for mobile, serve responsive files, and test loading performance.

July 25, 2026

Updated: July 25, 2026

To compress a restaurant menu image for a website, resize it to the largest width the page actually displays, then test WebP or AVIF against a JPEG or PNG fallback. Generate smaller width variants for mobile viewports, and inspect the smallest prices and allergen notes at the actual display size before exporting. Do not lazy-load a menu image that appears in the first viewport, and set its width and height attributes to reserve layout space. Treat file-size figures as starting budgets, not universal rules, and confirm the result with PageSpeed Insights and a real phone. Whenever possible, also publish the menu as selectable HTML text alongside the image.

Restaurant menus are an unusual compression case: they combine photography with dense, high-contrast text. The standard advice—compress until the photo looks fine—breaks down as soon as a blurry "8" looks like "3" or "$28" reads as "$2B."

Key Takeaways

WebP is a practical default for most menu images; AVIF may produce smaller files for photographic content, but test both and keep a fallback.
Resize to the largest CSS display width you need, then generate smaller variants for narrower viewports—do not ship a single desktop-sized file to every device.
Treat file-size figures as starting budgets; actual LCP performance is what matters, and that requires real measurement.
Never lazy-load a first-viewport or LCP menu image; consider fetchpriority="high" and add a preload only if profiling shows it is needed.
Set width and height on every <img> to help prevent image-related layout shifts.
Always verify text legibility at 100% zoom on a real device before publishing.
Publish the menu as HTML text alongside the image for accessibility and machine readability.

Why Restaurant Menu Images Need Different Compression Settings

A menu image carries dense, high-contrast text: small numerals, prices, allergen codes, and sometimes multi-column layouts. Three characteristics make compression riskier than for a typical food photograph:

Text artifacts are immediately obvious. Compression block noise and chroma errors blur fine strokes in ways that photograph grain never does.
High spatial frequency. Dense text means many edges per unit area—exactly what lossy compressors encode poorly at lower quality settings.
LCP exposure. When a menu image is the largest element visible on load, it directly affects your page's Largest Contentful Paint. Images are often among the largest page resources (HTTP Archive Web Almanac). Core Web Vitals, including LCP, are used as signals in Google's ranking systems (Google: Page Experience).

The compression strategy for a menu therefore prioritizes legibility first, then file size.

Choose the Right Format for Your Menu Type

Different menu types call for different format strategies. Use this table as a starting point, then test at your actual display size.

Menu type	Recommended format	Starting strategy	Key check
Photo-heavy menu (food photography + text)	Lossy WebP, AVIF with WebP fallback	Start at a moderate quality setting; compare both formats	All prices and dish names crisp at 100% zoom
Text-and-flat-color menu (digital design)	Lossless WebP or PNG	Lossless avoids compression artifacts on flat areas and thin text	No color banding or edge blur on headers
Scanned paper menu	Lossless WebP or high-quality lossy WebP	Scans already have noise; avoid compounding it with heavy lossy compression	Handwritten or serif text remains legible
Menu card / thumbnail in a grid	Lossy WebP or AVIF	Generate a small variant matched to the card display width	Key text (e.g., section title, price range) readable at thumbnail size

Format Comparison

Format	File size vs JPEG	Text legibility	Browser support (2026)	Notes
AVIF	Often smaller for photographic content (AOMedia)	Good at high quality; can soften fine text at aggressive settings	Current major browsers; use fallback	Slower to encode; test both AVIF and WebP
WebP	Roughly 25–34% smaller than JPEG at equivalent visual quality (Google WebP study)	Very good	Broad support in current major browsers (MDN)	Practical default for most menus
JPEG	Baseline	Good with tuning	Universal	Fallback for older environments
PNG	Larger (lossless)	Lossless, preserves source quality	Broad support	Preferred for text-critical or flat-color menus
SVG	Vector; not applicable	Scales perfectly	Broad support	Suitable for logos and icons; not a general solution for complex photographed or scanned menus

Resize the Menu Before You Compress It

The right dimensions come from your CSS layout, not from a universal number. Before exporting:

Identify the maximum CSS display width for the image across your breakpoints.
Multiply by the highest device pixel ratio (DPR) you want to support—commonly 1.5× to 2×—to determine your largest source file.
Generate smaller width variants for narrower viewports so mobile users download a file matched to their screen, not a desktop master.

A common example for a full-page menu might be a source file around 1,600–2,000 px wide with variants at 480, 800, 1,200, and 1,600 px. Treat those numbers as illustrative: your actual widths should follow your layout and the widths in your srcset.

Providing variants is more impactful than any single quality setting—a phone downloading a 1,600 px image when it only displays 400 px wastes most of those bytes regardless of format (web.dev: Serve responsive images).

Compress Without Blurring the Text

Starting points (test and adjust)

Start at a moderate quality setting and step down while zooming to 100% on a price or allergen note region:

For lossy WebP, a quality setting of around 80 (on a 0–100 scale) is a common starting point.
For AVIF, quality values around 60 are a common starting point in many encoders.

These are starting values, not universal minimums. Quality scales differ between encoders and are not directly comparable across formats. The right stopping point is when the smallest text on a real device remains clearly legible—not when the photograph looks slightly soft.

Chroma subsampling and colored text: Lossy encoding and chroma subsampling can cause color fringing on small, brightly colored text (e.g., colored price labels or allergen icons). If you see color errors on colored headers or small text, try a higher quality setting, switch to lossless WebP or PNG for that file, or use HTML text for those elements instead.

Illustrative compression decision example

The following is a simplified illustration. Actual results vary by image content, encoder, display size, and device.

Candidate	Format	Approx. file size	Text check result	Decision
Original	PNG (lossless)	~1.8 MB	N/A	Too large to serve directly
Option A	Lossy WebP, quality 85	~180 KB	Prices and allergen codes crisp	✓ Good starting candidate
Option B	Lossy WebP, quality 65	~95 KB	"$8" reads as "$B" on phone	✗ Over-compressed for this menu
Option C	AVIF, quality 60	~110 KB	Prices legible; slight softness on serif headings	Acceptable if headings are not critical

Your numbers will differ. Use this table as a workflow template, not as target values.

No-Code Workflow: Compress a Menu Image with LessMB

If you don't have access to command-line tools or image-editing software, LessMB offers a browser-based workflow that processes files locally on your device without uploading them.

Open lessmb.com and load your menu image.
Select your target output format (WebP or AVIF) and adjust the quality and output dimensions.
Zoom in to 100% in the preview and check the smallest prices, allergen notes, and footnotes.
If text looks blurry, increase the quality setting or switch to a lossless format.
Download the result when the text passes the zoom check.

LessMB can prepare individually optimized files. Generating multiple responsive width variants and writing the HTML markup for your website are separate steps that happen in your publishing workflow.

Developer Workflow: Serve the Right Menu Image to Each Screen

Use <picture> for format negotiation combined with srcset and sizes for responsive widths. Always set width and height to help prevent image-related layout shifts (MDN: Responsive images).

Below-the-fold menu image

For a menu image that appears below the first viewport, use loading="lazy":

<picture>
  <source
    type="image/avif"
    srcset="/menu-480.avif 480w, /menu-800.avif 800w, /menu-1200.avif 1200w, /menu-1600.avif 1600w"
    sizes="(max-width: 600px) 100vw, 800px"
  >
  <source
    type="image/webp"
    srcset="/menu-480.webp 480w, /menu-800.webp 800w, /menu-1200.webp 1200w, /menu-1600.webp 1600w"
    sizes="(max-width: 600px) 100vw, 800px"
  >
  <img
    src="/menu-800.jpg"
    srcset="/menu-480.jpg 480w, /menu-800.jpg 800w, /menu-1200.jpg 1200w, /menu-1600.jpg 1600w"
    sizes="(max-width: 600px) 100vw, 800px"
    width="1600"
    height="2200"
    alt="Dinner menu listing mains, sides, and allergen information"
    loading="lazy"
    decoding="async"
  >
</picture>

First-viewport or LCP menu image

If the menu image is the largest visible element on load, do not use loading="lazy". Add fetchpriority="high" as a hint to the browser:

<picture>
  <source
    type="image/avif"
    srcset="/menu-480.avif 480w, /menu-800.avif 800w, /menu-1200.avif 1200w, /menu-1600.avif 1600w"
    sizes="(max-width: 600px) 100vw, 800px"
  >
  <source
    type="image/webp"
    srcset="/menu-480.webp 480w, /menu-800.webp 800w, /menu-1200.webp 1200w, /menu-1600.webp 1600w"
    sizes="(max-width: 600px) 100vw, 800px"
  >
  <img
    src="/menu-800.jpg"
    srcset="/menu-480.jpg 480w, /menu-800.jpg 800w, /menu-1200.jpg 1200w, /menu-1600.jpg 1600w"
    sizes="(max-width: 600px) 100vw, 800px"
    width="1600"
    height="2200"
    alt="Dinner menu listing mains, sides, and allergen information"
    fetchpriority="high"
    decoding="async"
  >
</picture>

A <link rel="preload"> for the LCP image is only necessary if waterfall profiling shows the resource is discovered late. If you add one, use imagesrcset and imagesizes attributes to match the srcset and sizes values on the <source> elements, so the browser doesn't download the same resource twice (web.dev: Optimize LCP).

Loading strategy summary

Image position	`loading`	`fetchpriority`	Preload link
First viewport / LCP element	(omit or `eager`)	`"high"`	Only if profiling shows late discovery
Below the fold	`"lazy"`	(omit)	No

Do Not Use an Image as the Only Menu

A menu image—no matter how well compressed—contains text that screen readers cannot reliably parse and that search crawlers should not be expected to read via OCR. Following W3C guidance on complex images, provide a text alternative that conveys the same information:

Use a brief, purpose-describing alt attribute (e.g., alt="Dinner menu — mains and sides") rather than attempting to cram all dish names and prices into the alt text.
Publish the full menu as structured HTML on the same page or a linked page so that customers, screen readers, and search crawlers can access every dish name, description, price, and allergen note as selectable text.
Schema.org/Menu can be used to express the menu's structure in machine-readable form, but it should reflect the visible HTML content, not replace it. Google does not guarantee rich results or ranking improvements from menu structured data alone.

Pre-Publish Checklist

Work through this before publishing a menu image update:

Format and file

Menu is exported as WebP (or AVIF + WebP + JPEG fallback).
No source file is wider than needed for the largest CSS display slot at the highest DPR you support.
Responsive width variants exist for each major breakpoint in your layout.

Text legibility

Compressed file viewed at 100% zoom on a real phone.
Smallest prices, allergen codes, footnotes, and low-contrast text are clearly legible.
Colored text (if any) shows no color fringing or chroma artifacts.

Markup and performance

width and height set on every <img> to help prevent image-related layout shifts.
First-viewport menu image has no loading="lazy" and has fetchpriority="high".
Below-the-fold images use loading="lazy".
Preload link added only if waterfall profiling shows late resource discovery.

Accessibility

Brief, purpose-describing alt text on the image.
Full menu content also available as selectable HTML on the same or a linked page.

Verification

PageSpeed Insights or Lighthouse run; image-specific opportunities addressed.
If the site has sufficient traffic: CrUX 75th-percentile LCP confirmed at or below 2.5 s.

Common Mistakes

Serving a single large file to every device. A phone downloading a 3 MB desktop image gets none of the benefit of your compression work. Generate width variants.
Aggressive AVIF on small text. Prices and allergen codes blur before the photograph does. Test text readability, not just visual quality.
Lazy-loading the first-viewport menu image. This delays the most important paint. Remove loading="lazy" from any image that may be the LCP element.
Missing width and height attributes. Without them, the browser cannot reserve space for the image before it loads, which can cause layout shifts as the page renders.
Image-only menu with no HTML text. The image is what visitors see; the HTML text is what assistive technology and search crawlers can read. Provide both.
Treating quality numbers as universal minimums. A quality value that works for one encoder, image, and display size may not work for another. Always test at the actual output and device.

FAQ

What is the best image format for a restaurant menu image?

WebP is a practical starting point for most menu images, with broad support in current major browsers and smaller file sizes than JPEG for photographic content. AVIF may produce smaller files still, but the difference varies by image, encoder, and quality setting—test both. Keep a JPEG or PNG fallback for older environments, and always verify that the smallest prices and allergen notes remain legible at the actual display size.

How large should a restaurant menu image be for a website?

The right dimensions depend on how wide the image is displayed in your CSS layout and the device pixel ratio of your target screens. A common starting point for a full-page menu is a source file around 1,600–2,000 px wide, with smaller variants served to narrower viewports. Treat file-size figures as initial budgets and adjust based on real LCP measurements.

Will compression make menu text unreadable?

It can, if you reduce quality too aggressively or downscale below the intended display size. Work from the largest dimension the layout actually uses, choose a starting quality, zoom to 100% on a real device, and check the smallest prices, allergen notes, and footnotes before finalizing the file.

Should I lazy-load a restaurant menu image?

Do not lazy-load a menu image that appears in the first viewport. For images below the fold, lazy loading reduces unnecessary network requests. If a menu image is the page's largest above-the-fold element, add fetchpriority="high" to it; add a preload link only if profiling shows the resource is discovered late (web.dev: Browser-level lazy loading).

Should a restaurant menu be an image or HTML?

Publish both when possible. An image works well for design-heavy or scanned menus, but the text inside is not reliably accessible to screen readers or search crawlers. Providing a structured HTML version of the same content alongside the image gives customers, search engines, and assistive technology a machine-readable menu.

Is PNG better than WebP for a text-heavy menu?

Lossless WebP and PNG both preserve text without compression artifacts, at the cost of larger files. Try lossless WebP first: it is lossless and typically produces smaller files than PNG. Use lossy WebP or AVIF only for photographic menus where some quality reduction is acceptable, and always verify text legibility after compressing.

Can I publish a PDF menu instead of an image?

A PDF that contains selectable text is better for text accessibility than a raster image, but it typically renders less well on mobile than a dedicated HTML menu or a well-optimized image. If you already have a PDF menu, link to it as a supplementary download while also providing a mobile-friendly image and an HTML text version on the page.

How do I test whether a compressed menu is still readable?

Open the compressed file at 100% zoom on a real phone, or use browser DevTools set to a small viewport and the highest device pixel ratio you support. Look specifically at the smallest printed prices, allergen codes, footnotes, and any low-contrast text. If any are blurry or ambiguous, raise the quality setting or switch to a lossless format for that file.

Does compressing a menu image improve Core Web Vitals?

Reducing image file size can lower Largest Contentful Paint when that image is the LCP element, but it is one factor among many. Core Web Vitals scores reflect real user data at the 75th percentile. Run PageSpeed Insights or Lighthouse to identify image-related opportunities, and confirm real-user LCP with CrUX data if your site has enough traffic (Google: Page Experience).