Photos Rejected on One OTA, Fine on Another? 2026 Spec Comparison Across 6 Platforms
Same photo set, six different verdicts
A friend who runs a small guesthouse asked me about this, and it turned out to be more interesting than I expected.
He uploaded one batch of room photos to Booking.com, Agoda, and Expedia on the same afternoon. Booking accepted them. Agoda bounced them for insufficient resolution. Expedia flagged the listing as incomplete because of room-type photo counts. One batch, three outcomes.
Nobody is wrong here. The specs genuinely differ, and they differ by more than you would guess.
I spent an evening pulling the published requirements from every partner portal I could access. What struck me was not any single number — it was that no one appears to have put these side by side. Each platform buries its rules in its own help center, so unless you run six channels simultaneously, you never see the spread.
One boundary up front: the figures below come from official partner documentation and GIATA's channel-requirements roundup. I did not upload test images to measure each platform's compression — that needs merchant backend access on six platforms, which I do not have. I will show you how to test that part yourself.
Listing-side specs: the real spread
| Platform | Minimum | Recommended | Per-file cap | Count requirements |
|---|---|---|---|---|
| Booking.com | 300px (per GIATA) | 2048x1080 min, 4000x3000 preferred | Not published | 10+ suggested, 45 max |
| Agoda | 800x600 | 2048x1536 | 4MB | 24 property-level, 4 per room type |
| Expedia group | 1000px | 2880px | Not published | 20 min, 4 per active room type incl. bathroom |
| Kayak | 640px | Not published | Not published | 35 max |
| Tripadvisor | Not published | 2880px | Not published | Not published |
| Airbnb | 1024x683 | 2048px wide+ | Not published | Varies by listing type |
The gap between Booking's preferred 4000x3000 — twelve megapixels, camera territory — and Kayak's 640px floor is roughly forty times the pixel count. Feeding one asset set to both ends is not a plan, it is a coin flip.
Agoda's 4MB per-file ceiling is the one people actually hit. Modern phones produce 5MB files casually, and ProRAW blows past 20MB. Uploads fail without a clear reason, and people burn an afternoon on it. Agoda also caps a single upload batch at 100MB total, so thirty large files in one go will not land.
Expedia's rule that every active room type needs four photos including a bathroom shot is my favorite, because it is not a technical constraint at all. It is conversion-driven — their data says travelers hunt for bathroom photos. Skip it and the room type loses ranking weight.
The column nobody mentions: how long until it goes live
This one bit my friend harder than the rejections.
Booking refreshes within minutes. Expedia twice daily. Tripadvisor takes 24–48 hours. Agoda updates on a bi-weekly cycle, and images can take upwards of two weeks to actually appear.
Two weeks. If you swap in seasonal photos the week before a holiday, Agoda simply will not make it.
Traveler-side: review photos work differently
If you are not an operator and just want to leave a review, an entirely separate ruleset applies — and it is built around incentives, not image quality.
Klook publishes its thresholds openly: upload 3 or more photos and a review earns 30 KlookCash; write 100 characters or more and it earns another 20. So "three photos" is a deliberate design threshold, not an arbitrary limit.
Airbnb, by contrast, does not pay for review photos at all — it weights them into host and guest reputation instead. Different incentive, different behavior: Airbnb review photos skew toward complaints, since satisfied guests rarely bother.
Frankly, transparency on this side is much worse than on the listing side. I could not find published per-file limits for review uploads on most platforms, so I am marking them unknown rather than inventing a number.
Test the compression yourself
Specs are one thing. What the platform actually does to your file is another. Every OTA re-encodes uploads and generates multiple derivative sizes. The only question is how much you lose.
Three steps, no special tooling:
- Upload an image you still hold the original of. Note the original file size and pixel dimensions.
- Find it on the public-facing page and copy the image address. Open that URL directly. Watch for size parameters in the path or query string (
_R_1200x800,?w=1080) — those indicate dynamic resizing. - Save that file and compare size, actual pixels, and whether EXIF survived.
exiftoolor any online EXIF viewer will do.
Step three is the one that matters most. If a platform does not strip EXIF, your property photos may still carry GPS coordinates — which for a small rental means publishing the address. More than one host has learned this the hard way.
The same methodology applied to image hosts is written up in our field-by-field EXIF retention test across 8 hosts — it ports directly to OTA platforms.
Why one master file for all channels backfires
The tempting move is to shoot at maximum quality once and push identical files everywhere. Three problems.
Bigger is not automatically safer. Agoda's 4MB ceiling rejects your 12MP original outright. Compress everything under 4MB to satisfy Agoda and Booking's quality score drops.
Crop ratios destroy composition. Agoda explicitly wants landscape orientation. A vertical shot loses the ceiling on one platform and the foot of the bed on another.
Go-live lag desynchronizes your channels. Booking updates in minutes, Agoda in two weeks. In between, the same room looks different depending on where the guest is shopping. That is where complaints come from.
Practical setup is two or three variants: a high-resolution master around 4000x3000 for Booking and Expedia, a landscape version under 4MB for Agoda, and a 4:3 version for activity channels. Build it once and every seasonal refresh reuses the pipeline.
Where to park the intermediate files
Producing three variants creates an annoying side problem: you need somewhere to stage them and a way to show them to a photographer, a designer, or whoever handles your listings.
Email attachments get recompressed. Cloud drives demand the other party sign in. Messaging apps flatten quality.
For that short-lived "send someone a link they can open and see the real file" need, an image host beats a cloud drive. On lpic.cc it is upload, optionally set a view password, copy the short link, send. No signup on either end, and the password matters if the property has not launched publicly yet.
Limits, so you use it in the right place: images cap at 8MB — which means Booking-grade 4000x3000 masters may not fit — files are retained for 30 days after the last view, and uploads are automatically optimized, so originals are not preserved.
It is a staging post, not an asset library. Keep your masters on your own storage. No exceptions on that one.
FAQ
Q1: What gets photos rejected most often?
From the published specs, the top three are insufficient resolution, exceeding the per-file cap, and wrong orientation (Agoda takes landscape only). Booking.com also explicitly rejects grainy, blurry, over-processed, or watermarked images — so a logo in the corner of your photo is a likely culprit.
Q2: Is a phone camera good enough, or do I need a photographer?
On paper, a flagship phone's 12MP output (roughly 4032x3024) lands right on Booking's preferred 4000x3000. The real gap is lighting and composition, which resolution cannot fix. On a budget, prioritize the hero shot and the bathroom — those carry the most weight.
Q3: How do I get under Agoda's 4MB limit?
Drop JPEG quality to 80–85 and an 8MB file typically lands around 3MB with no visible difference. Do not shrink dimensions to get there — that costs you resolution score at the same time.
Q4: Can I delete review photos after posting?
Most platforms let you remove your own review and its images, but cached thumbnails and copies already surfaced elsewhere do not reliably disappear. Photos you might regret should never go up in the first place.
Q5: Why no compression benchmarks in this article?
Testing listing-side compression requires merchant backend accounts on six platforms, which I do not have. Review-side photos are public but belong to other people, so scraping them to measure is not something I am willing to do. I would rather publish verified specs plus a test you can run than hand you numbers with no provenance.