[Rejected] Add `width` and `height` fields to each image entry in the `/at-home/server/:chapterId` API response.

[realrnvr]

## Current Response

{
  "result": "ok",
  "baseUrl": "https://uploads.mangadex.org",
  "chapter": {
    "hash": "3303dd03ac8d27452cce3f2a882e94b2",
    "data": [
      "1-f7a76de10d346de7ba01786762ebbedc666b412ad0d4b73baa330a2a392dbcdd.png",
      "2-2a5e95dfec7f15cd01f9a63835be18a22fb77a10fd2d62858c7dcbb6e6c622f9.png"
    ]
  }
}

## Proposed Response

{
  "result": "ok",
  "baseUrl": "https://uploads.mangadex.org",
  "chapter": {
    "hash": "3303dd03ac8d27452cce3f2a882e94b2",
    "data": [
      {
        "filename": "1-f7a76de10d346de7ba01786762ebbedc666b412ad0d4b73baa330a2a392dbcdd.png",
        "width": 728,
        "height": 1080
      },
      {
        "filename": "2-2a5e95dfec7f15cd01f9a63835be18a22fb77a10fd2d62858c7dcbb6e6c622f9.png",
        "width": 1456,
        "height": 1080
      }
    ],
    "dataSaver": [
      {
        "filename": "1-27e7476475e60ad4cc4cefdb9b2dce29d84f490e145211f6b2e14b13bdb57f33.jpg",
        "width": 364,
        "height": 540
      }
    ]
  }
}

## Motivation

Image dimensions are currently unavailable through the API, which creates a significant challenge for third-party readers implementing double page / spread detection.

Without dimensions, readers are forced into one of the following workarounds:

• Fetch each image partially or fully just to read its header — adds 8-10 seconds of loading time for a typical chapter (~50-60 pages), even with parallel requests and HTTP Range headers
• Build and maintain a separate image dimensions database — requires proxying all images through your own server, significant infrastructure overhead
• Use heuristics (aspect ratio thresholds) — unreliable, produces incorrect pairings for edge cases
• Leave it to the user (offset toggles, manual mode) — poor UX, especially for new readers.

MangaDex already validates image resolution during upload (enforcing the 10,000px limit), which means the dimensions are already known and stored server-side. Exposing them in the API response would cost nothing on MangaDex's end and would be a significant quality-of-life improvement for every third-party reader built on the API.

## Use Cases

• Double page spread detection — determine whether consecutive portrait pages should be paired, or whether a landscape page should be displayed solo
• Reader layout calculation — calculate correct image fit and aspect ratio before the image loads, eliminating layout shifts
• Preloading optimization — allocate correct dimensions in the UI before images arrive, improving perceived performance
• Efficient preloading — without dimensions, readers must either load all images upfront to determine layout, or risk layout shifts when images load progressively. With dimensions available ahead of time, readers can load only the images currently needed (e.g. current page and next 1-2 pages) and preload ahead as the user navigates — rather than fetching the entire chapter upfront just to figure out the spread layout. This significantly reduces bandwidth usage and improves load times, especially on mobile connections.

## Backward Compatibility

This change could be introduced as an opt-in via a query parameter to avoid breaking existing integrations:

GET /at-home/server/:chapterId?includeDimensions=true

This way existing clients are completely unaffected.

## Conclusion

This is a small addition to an existing endpoint that would meaningfully improve the developer experience for anyone building a reader on top of the MangaDex API, and directly benefit end users through faster load times and more accurate page layouts.

 

[EtherealNeko]

Rejected.