I typed one page number twice and the tool deleted a page I never picked
I was testing our Delete PDF Pages tool for a blog post on the Korean side of the site, the kind of routine verification I do before writing about anything. Upload a file, type some page numbers, confirm it does what it says. It does, right up until you fat-finger the same number twice, at which point it quietly deletes a page you never asked to touch.
The setup
I built a 5-page test PDF with each page labeled PAGE 1 through PAGE 5, so there's no ambiguity about what survives. The tool itself is simple: upload a PDF, type the pages you want gone into a text box, click Delete, download the result.
The control run
Typed 2, 4. The tool reported "Deleted 2 pages. 3 left." I downloaded the result and read it back with pdf.js: pages 1, 3 and 5, in order. Exactly what I asked for. Zero network requests the whole time, confirmed with a request listener attached before the upload.
Then I typed the same number twice
New upload, same 5-page file. This time I typed 2, 2, 4, the kind of thing that happens if you paste a number twice or miscount while editing a list. The tool reported "Deleted 3 pages. 2 left." I'd only named two distinct pages, so a message about 3 deletions should have been the first red flag, except there's no second check built into the flow, you just see a number and a download button.
I downloaded it anyway and opened it. Pages 1 and 5 survived. Pages 2, 3 and 4 were gone. Page 3 was never in my input.
Why this happens
My best guess, without having read the minified source line by line: the tool removes pages from the end of the list backward to avoid index drift (a sound approach for a single pass over distinct page numbers), but it never deduplicates the input first. So typing 2 twice means it removes "index 2" twice, and the second time, whatever shifted into that slot after the first removal goes with it. A list, not a set, running against indices, not page identities.
What I checked to rule out
I reran the same file with 2, 4, 8 (page 8 doesn't exist in a 5-page file). That one worked correctly: "Deleted 2 pages. 3 left," and the download matched. So the bug isn't about invalid page numbers, it's specifically about repeating a valid one. I reproduced the exact duplicate-number failure three separate times across two browser tabs before writing this up.
What I'd do until it's fixed
Check that the deleted-page count in the success message matches the count of distinct numbers you typed, not just that you typed something. And actually open the downloaded file before you trust it for anything that matters, because the UI gives you no other signal that something went wrong.
Where this fits
This is on the Korean satellite site, not the hub's /tools/ catalog, and it's a straightforward dedupe-before-delete bug, not a privacy or upload issue, the zero network requests held throughout. I've flagged it internally. If you're using it in the meantime: don't type the same page number twice, and verify your output.
Related: I fed a barcode generator the same number twice. It caught every typo except that., I merged two PDFs and counted the network requests: zero, API docs.