Grubhub menu photo rules: square, food only, so specials go in video

Grubhub menu photos must be square and show food only, and specials images are rejected. Make the specials as a 9:16 video with Sume Timeline and caption cues.

4 min readSume
All posts

Grubhub's menu photo rules leave no room for a "Today's special" graphic: photos must be square and show food only. So keep the menu photos as plain food shots, and put the specials where text is welcome, in a short vertical video that you post on your own channels. Sume builds that video from the dish photos you already have, with one Timeline render and burned-in caption cues for the dish names and prices.

What does Grubhub allow in a menu photo?

The restaurant help page on menu photos lists these rules, read on 2026-10-03. Photos must be 1:1 (square) and at least 200x200 pixels. They must show food only; Grubhub says it rejects images of coupons, weekly specials, and restaurant interior or exterior. Logos need a background color (white is acceptable) and must be saved as .png. Adult content, violence and medical imagery are not allowed, and images must not return matching URLs from a reverse Google image search.

Grubhub menu photo rules from Grubhub's restaurant help page, read 2026-10-03, with where each leaves your specials.
Rule on the pageWhat it means for specials
1:1 square, at least 200x200Crop dish photos square for the menu
Food onlyNo text graphic, coupon or specials board in the photo
Rejects coupons, weekly specials, interior or exteriorPut specials in a separate asset
Logos need a background color, .pngKeep the logo out of the dish photo
No matches in reverse image searchUse your own original photos

Where do specials go instead?

Into a video that you control. A 9:16 Timeline render is 1080x1920 by default, which suits a Story, Reel or Short. Use three or four dish photos as slots of 3 to 5 seconds, and put the dish and price in cues. The Video captions guide says cues burn exactly the text you supply and skip speech-to-text, which a silent video needs. The render itself is $0.10 per output minute, so a 15-second reel is $0.10 as well.

curl -X POST https://api.sume.com/v1/timeline-1.0/render \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: specials-001" \
  -d '{
    "audio": { "mode": "silence", "duration_seconds": 15 },
    "video": [
      { "source_url": "https://media.sume.com/artifacts/artf_d1/ramen.jpg", "start": 0, "duration": 5 },
      { "source_url": "https://media.sume.com/artifacts/artf_d2/gyoza.jpg", "start": 5, "duration": 5,
        "transition": { "type": "fade", "duration": 0.25 } },
      { "source_url": "https://media.sume.com/artifacts/artf_d3/mochi.jpg", "start": 10, "duration": 5,
        "transition": { "type": "fade", "duration": 0.25 } }
    ]
  }'

How do I add the dish names and prices?

Take the render's video_url and submit a caption job with cues: one cue per dish, start and end in seconds, text as you want it read, for example "Tonkotsu ramen, $14". Check each price and the allergen wording by eye before you post. Sume burns exactly what you write and does not check it.

Can AI make the menu photo itself?

Sume's image API can generate a square dish image, since every model's supported aspect ratios are listed in GET /v1/images/models, and 1:1 is the first thing to look for there. Grubhub's page, though, does not say whether it accepts AI-made food photos, and it asks for photos that do not match other images online. For a real menu, the safest asset is a real photo of the real dish. Use generated images only for backgrounds or promo art on your own channels, and do not show a dish you do not serve.

What is a simple weekly routine?

Shoot or crop the dish photos square once, and upload them to Grubhub. Each week, reuse the same photos in a new Timeline render with that week's cues. The photos stay compliant on Grubhub and the specials change on your own channels, for about ten cents a week plus the caption job.

Sources

Related posts

More in Use cases

All Use cases posts

Written by Sume