Two sites, two clients, seven weeks apart, and the same lesson. In both cases the server answered with a 200, the code for success. In both cases the reader saw something broken. Anyone checking from a desk would have signed the page off.
Black slots on an iPhone
On September 15, 2026 the photographs in Intendance Palace’s articles appeared as black blocks. Only on iPhones and Safari. On a PC, in Chrome or Firefox or Edge, every image was there, which is why it could have stayed unnoticed for a long time.
The cause had three parts, and each one was reasonable alone.
The format was chosen for us. The site’s images were delivered by Cloudinary with its automatic format setting, which picks a format according to what the browser says it accepts. Safari 17 added JPEG XL (WebKit, 2023), so Safari asked for JPEG XL and received it, while Chrome received WebP.
Nothing capped the size. In all, 25 photographs were above 4,096 pixels. The largest was 11,507 by 5,521, with originals of up to 10.7 MB, and it was being delivered at full size: 63 megapixels sent to a 340 pixel card. On a phone, the browser gave up on the image and left the slot empty.
The design hid the failure. The site paints a dark ink colour behind each photograph, which looks elegant while an image loads. An image that never decodes therefore looks like a deliberate black block. On a white background it would have looked broken and been reported sooner.
Every server response in that chain was a success. The file existed, the type was valid, and the browser had asked for exactly what it received.
We fixed it with one rule. Every image address is now built by a single function that names the format, WebP, and caps the width for the place the image will appear. The build refuses to finish if it finds any image address that does not follow the rule. And every Monday a check requests every image on the live site twice, once as Chrome and once as Safari, and reports anything off.
That last part is the one we would keep if we could keep only one. An automatic setting is a choice you have not read. If you cannot list the formats a page might deliver, you cannot test them.
A 200 says the server answered. It tells you nothing about what the reader saw.
A map with a watermark
On November 5, 2026 we found the map on the MGNI property pages stamped “API KEY REQUIRED”.
The map tiles came from a free service that now wanted a key. It had made the change politely: every tile still answered 200, with the type image/png. Each one was exactly 2,049 bytes, because each one was the same picture of the same watermark.
A status check passes that. A type check passes that. Only two things catch it: comparing the byte size, since real map tiles vary, or looking.
We moved the map to OpenStreetMap tiles with the required attribution (OpenStreetMap), toned down to sit quietly in the page, and confirmed the change on the live site.
Why these failures are so easy to miss
01 / 04
Did the server answer?
Black photos
Yes, 200
Watermarked map
Yes, 200
02 / 04
Is it the right type?
Black photos
Yes, a valid image
Watermarked map
Yes, image/png
03 / 04
Does it work on my machine?
Black photos
Yes, on a PC
Watermarked map
Only if you look at the map
04 / 04
What did the reader get?
Black photos
A black block
Watermarked map
A watermark
| What the check asks | Black photos | Watermarked map |
|---|---|---|
| Did the server answer? | Yes, 200 | Yes, 200 |
| Is it the right type? | Yes, a valid image | Yes, image/png |
| Does it work on my machine? | Yes, on a PC | Only if you look at the map |
| What did the reader get? | A black block | A watermark |
Most monitoring stops at the first row, and most sign-off stops at the third. The failures in this note live in the last one.
What a real check looks like
- Ask as each browser your readers use. Safari on a phone is the one most often skipped.
- Check what came back: its size, its dimensions, whether it varies when it should.
- Name your formats and cap your widths, so that the possibilities can be listed.
- Look at the page, on a phone, on a schedule.
