I exported a long PDF page at 300 DPI and got 131: the WebP 16383 cap

A developer testing ImgIng, a browser-based PDF and image tool, found that WebP exports of a tall PDF page silently cap at 16383 pixels per side, so requests for 300, 216 and 144 DPI all produced identical 1456×16380 files — an effective 131 DPI — with no error or warning. Cross-engine canvas tests showed Chromium quietly crops oversized WebP output to 16383 rows, Firefox returns null, and WebKit substitutes PNG at full size, while JPEG hit its own ceiling at 65500 rows in Chromium. The developer recommends dividing 16383 by the page height in inches to find the maximum achievable DPI and verifying exported dimensions after the fact.

I had one PDF page that is 800×9000 pt. It's a test page I generated myself: thirty blocks of text, plus a BOTTOM-MARK line at the very end so I could tell whether anything got cut. I wanted it as a single tall image. I used ImgIng https://imging.ai/ https://imging.ai/ , a browser-based PDF and image tool, in Chromium 149 on an Apple M4 Mac, and exported to WebP. At 300 DPI I got 1456×16380. At 216 I got 1456×16380. At 144, same again. All three files were 1,213,414 bytes. No error and no warning. The result card just listed the size. So the first job was working out what resolution I actually had. PDF measures in points, 72 to the inch. This page is 800 pt wide, which is 11.11 inches, and 1456 px divided by 11.11 in is 131. That's the effective DPI, whatever the dropdown said. The aspect ratio came out at 11.25, same as 9000/800, and the bottom mark was still there on row 16379. Nothing was cropped. The whole image had been scaled down evenly. At 216 DPI the page should be 2400×27000. A WebP file stores width and height in 14 bits each, so neither side can go past 16383. The output is 16380 tall, three pixels under. Shrink the page until its height fits and the width shrinks with it, down to 1456. Every DPI option above 131 hits that same wall, 144 included, which is why all three exports were byte-identical. To check that the wall belongs to WebP and not to the tool, I exported the same page as JPG and PNG. At 144 DPI I got 1600×18000, a true 144. At 216 and 300 both formats landed on 2385×26832 and 2385×26834, about 215 effective DPI. So those formats go well past 16383 and stop somewhere else. From the sizes it looks like a total-pixel cap near 64 million, but that's my guess. I didn't find it documented. One thing I can only report, not explain. When the same tool stitches several pages into one long image, JPG and PNG are also held under 16383. Eight A4 pages came out at 1446×16376 in both WebP and JPG, which is 175 effective DPI. I haven't seen the code, so I don't know why that mode follows the WebP limit for every format. If you build this in your own front end, the canvas is where you meet the limit. I asked three engines to export a 1786×20208 canvas as WebP and as JPEG, then decoded whatever came back: js async function exportedSize w, h, type { const c = document.createElement 'canvas' ; c.width = w; c.height = h; c.getContext '2d' .fillRect 0, 0, w, h ; const blob = await new Promise r = c.toBlob r, type, 0.8 ; if blob return 'null'; const bmp = await createImageBitmap blob ; return ${blob.type} ${bmp.width}x${bmp.height} ; } | Engine | WebP request | JPEG request | |---|---|---| | Chromium 149 | image/webp 1786x16383 | image/jpeg 1786x20208 | | Firefox 151 | null | image/jpeg 1786x20208 | | WebKit 26.5 | image/png 1786x20208 | image/jpeg 1786x20208 | Chromium is the quiet one. It hands back a valid WebP that is 16383 tall. An earlier run with a gradient and color bars showed the missing rows are cut off the bottom, not scaled. Firefox gives you null, which at least you can catch. WebKit switches the format to PNG and keeps the size, so blob.type is what to look at there. JPEG has its own ceiling too: Chromium returned 65500 rows when I asked for 65535. Put the tool and the engines side by side and you get several ways to hit the cap without any error. Scaling keeps every line of content and costs resolution. Cropping keeps resolution and loses the bottom of the page. Swapping formats keeps both and changes what you ship. Back when I worked on codecs, the tickets that took me longest to close looked like this one: every call succeeded and the output was still wrong. Before exporting I divide 16383 by the total height in inches. That's the best DPI a WebP long image can reach: about 175 for eight A4 pages, about 70 for twenty. After exporting I divide the image width by the page width in inches and compare the two. In my own code I decode the blob and check that width, height and type match the request before saving. When they don't match, I split the pages into shorter runs instead of shipping a 23 DPI image of a 60-page document.