I build editpdf.tools, free PDF and image tools that run in the browser. Users asked for iPhone HEIC support, so I added it. Then I tested everything on my own iPhone, and the phone had opinions.
Bug 1: "WebP" files the size of PNGs
I converted a photo to WebP on the iPhone. The file was as big as a PNG. Because it was a PNG. Safari does not support WebP in canvas.toBlob(), and instead of throwing, it hands back image/png. My code trusted the requested type and named it .webp.
Lesson: always check blob.type after toBlob(). I now fall back to a small browser WebP encoder that loads only when the native result is wrong.
Bug 2: rotated pages in the PDF
A form photo came out sideways in Image to PDF. The thumbnail looked fine. The PDF did not. Phone cameras save sideways pixels plus an EXIF orientation tag; browsers apply the tag, PDFs do not. I was embedding raw JPEG bytes.
Lesson: if you embed images into PDFs, read the EXIF orientation yourself and rotate on the page. It took about 30 lines and no second encode.
Bug 3: "JPG or PNG" while HEIC worked
On iPhone, HEIC already "worked" in Image to PDF before I touched it, because iOS converts HEIC to JPEG when a site only accepts JPG and PNG. On Windows the same file simply could not be selected. Two devices, two different truths. I added real HEIC and WebP support so the page text and the behaviour match everywhere.
What I would tell myself last week
Test on the phone your users have. Desktop dev tools are not enough.
Silent fallbacks are worse than errors. Check what you actually got.
Your support inbox is the best roadmap you have.
Everything still runs on the user's device, so photos are not uploaded.
Try it: https://editpdf.tools/image-to-pdf and https://editpdf.tools/image-format-convert
Found another edge case? Tell me in the comments, through https://editpdf.tools/contact, or at support@editpdf.tools.
