Telegram: wrong type of the web page content

[illmouse]

Hi everyone,

I’ve been searching through the issues but couldn’t find anything related to this problem.

I’m running into an issue with the Telegram Bot API when trying to send an image URL generated by Jellyfin.

Jellyfin sends the following webhook:

{
  "chat_id": "<chat_id>",
  "photo": "https://jellyfin.example.com/Items/8c9416b8-19f7-f70a-8e92-ff6ef9e355b6/Images/Primary.jpg",
  "caption": "<b>Movie Now Available</b>\n\n<b>My Best Movie (2025)</b>\nDescription here",
  "parse_mode": "html",
  "protect_content": true
}

The Telegram API responds with:

{
  "ok": false,
  "error_code": 400,
  "description": "Bad Request: wrong type of the web page content"
}

I also tried sending the same request using curl:

curl -X POST "https://api.telegram.org/bot<token>/sendPhoto" \
  -H "Content-Type: application/json" \
  -d '{
    "chat_id": "<chat_id>",
    "photo": "https://jellyfin.example.com/Items/8c9416b8-19f7-f70a-8e92-ff6ef9e355b6/Images/Primary.jpg",
    "caption": "<b>Movie Now Available</b>\n\n<b>My Best Movie (2025)</b>\nDescription here",
    "parse_mode": "html",
    "protect_content": true
  }'

I get the exact same error:

{
  "ok": false,
  "error_code": 400,
  "description": "Bad Request: wrong type of the web page content"
}

After checking the image URL with curl, I noticed it returns this header:

content-disposition: attachment

This header forces the client to download the image instead of displaying it inline.

I’m wondering if this could be the cause of the issue. Maybe Telegram rejects images served with content-disposition: attachment?

It’s unclear whether this behavior changed on Telegram’s side or Jellyfin’s side, but it seems related to how Jellyfin serves images.

For comparison, sending an image from a standard public URL works without any issues, for example:

https://images.wallpapersden.com/image/wxl-wednesday-2-iphone-jenna-ortega_93159.jpg

Has anyone run into a similar issue?

Jellyfin version: 10.11.6

[Lowitle]

I have the same issue.

I tried to:

curl -I https://myjellyfin.mydomain.synology.me/Items/569fb256-6ea9-1456-a524-b6842918223e/Images/Primary

and I got

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 18 Feb 2026 17:24:01 GMT
Content-Type: image/jpeg
Content-Length: 1125902
Connection: keep-alive
Keep-Alive: timeout=20
Age: 3268
Cache-Control: public
Last-Modified: Wed, 18 Feb 2026 16:29:33 GMT
Vary: Accept
transferMode.dlna.org: Interactive
realTimeInfo.dlna.org: DLNA.ORG_TLAG=*
Content-Disposition: attachment
X-Response-Time-ms: 0.6657
Strict-Transport-Security: max-age=15768000; includeSubdomains; preload

Talking to Deepseek told me that the problem is in Content-Disposition: attachment. But I don't know how to continue from this.

The options that Deepseek tell me is about modifying nginx, but I can't do much since my nginx is build-in my synology DSM.

I would like some feedback about that.

[tuhlaajapoika]

@illmouse @Lowitle I had similar issues randomly. I tried adding ?maxHeight=400&maxWidth=400&quality=90 at the end of the photo URL and notifications went through successfully. I'm not sure what the issue is, though. The original photo of was only 640x360 at 40.6KB and resized one is 400x225 at 20.9KB.

Like this:

"photo": "https://jellyfin.example.com/Items/8c9416b8-19f7-f70a-8e92-ff6ef9e355b6/Images/Primary.jpg?maxHeight=400&maxWidth=400&quality=90",

Edit. Weirdly, it works with ?maxHeight=1200&maxWidth=1200&quality=90", too eventhough it exceeds the original image, and with or without the quality part.

[illmouse]

@tuhlaajapoika tried to fiddle with this params, but getting the same result - {"ok":false,"error_code":400,"description":"Bad Request: failed to get HTTP URL content"}

[tuhlaajapoika]

There's one more thing I had to change but forgot to mention. You seem to use subdomain too, do you have any trailing slashes in the "Server URL" field at the top of webhook plugin's settings?

I had https://jellyfin.example.com/ previously as it says below the field to "Include base url", which is empty basically. I noticed that the server logs had double forward slashes "photo": "https://jellyfin.example.com//Items/8c94...", so I had to remove the trailing forward slash and use https://jellyfin.example.com, otherwise the notifications wouldn't work. After that I appended the ?maxHeight=400&maxWidth=400&quality=90 bit, without it some notifications would fail.