I Shipped HEIC Support. Then My iPhone Found 3 More Bugs.

Chandan Singh — Sun, 01 Nov 2026 18:43:09 +0000

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.

I built PDF tools that never upload your files. Here is what I learned

Chandan Singh — Wed, 28 Oct 2026 13:44:40 +0000

A few weeks ago we launched editpdf.tools, a set of free PDF and image tools that do their work inside the browser instead of on a server. I want to share what the product looks like now and three lessons that changed how we build it.

What it is

15 tools in total. The 14 free ones run on the user's device, with no signup and no watermark: merge, split, compress, sign and fill PDFs, add page numbers or a watermark, image to PDF, image compress and resize to an exact KB size, format conversion, ID card front and back on one page, and a video frame extractor.

The one exception is Edit PDF, a paid tool that changes existing text inside a PDF. That kind of editing needs a server, so that file is uploaded for processing and not stored. We label it clearly instead of pretending everything is local.

Lesson 1: The real problem is often the steps around the tool

When I looked at how people around me sign a PDF, signing was not the hard part. The usual route was: sign on paper, take a photo, open one website to remove the photo background, then upload the PDF to another website to place the signature. Three sites, two uploads, and a signature that still looked pasted on.

So our PDF Sign tool lets you draw the signature in the browser on a transparent background and place it on the page. No photo, no background remover, no upload. The fix was not a better signing algorithm. It was removing the detour.

Lesson 2: Build for the moment people are stuck

Almost everyone has been here: you are at a bank or an office counter, they ask for a copy of both sides of your ID, and you don't have one. People end up looking for a photocopy shop and handing their ID to a stranger.

That became our That became our ID Front and Back to PDF. On a phone you tap Take photo for each side, crop, choose the layout, and get a print-ready PDF in about a minute. It is not a complex tool. It just matches a real moment.

Lesson 3: Privacy needs proof, not a promise

"Your files are safe with us" is on almost every PDF site. It means nothing on its own. So instead of only writing it, we recorded a short video that opens the browser's Network tab while using the tools and shows that no file is sent. It is on our security page, and anyone can repeat the test on any site.

Being honest about the one tool that does upload made the rest of the claim more believable, not less.

What I would love feedback on

Which PDF or image task do you still do with an upload-based tool because nothing else works?
If you test the Network tab yourself, does anything look unexpected?
What would make you trust a new tool with a sensitive document?

Thanks for reading. I will reply to every comment.

Chandan,
editpdf.tools