Building a no-signup PDF toolkit with 32 small file tools

I recently built PDFem, a no-signup toolkit for small PDF, image, and document tasks.

The idea came from a very ordinary frustration: most file conversion tasks are tiny, but the tools around them often feel bigger than the problem.

You want to merge a PDF, compress an image, convert a Word document, rotate a page, or extract text. That should be a quick utility flow, not a full account creation moment.

So I wanted PDFem to feel simple:

Open the tool
Upload the file
Choose an option if needed
Download the result

No dashboard. No forced signup. No long onboarding.

What it includes

PDFem currently has 32 tools across a few groups:

PDF tools like merge, split, compress, rotate, protect, unlock, reorder, watermark, and page numbers
Convert-to-PDF tools for JPG, PNG, Word, Excel, PowerPoint, HTML, and HEIC
Convert-from-PDF tools for JPG, PNG, Word, Excel, PowerPoint, text, and extracted images
Image tools for compression and format conversion, including WebP, JPG, PNG, SVG, and HEIC workflows

The product sounds simple from the outside, but building it reminded me how many details hide inside “small” utilities.

The hidden work behind a simple upload button

The upload button is the easy part.

The harder parts are the states around it:

What happens if the file is too large?
What happens if the extension says .pdf, but the file is not really a PDF?
What happens if a conversion fails halfway through?
How long should generated files stay available?
How should multi-file tools handle ordering?
What should the UI show while the server is still working?
How do you keep tool pages consistent without making every page feel generic?

File tools are mostly about trust. If the flow is confusing or the error message is vague, people leave quickly.

Choosing boring architecture on purpose

I kept the app fairly traditional.

The frontend is server-rendered, and the backend handles the conversion flow through separate tool modules. Some jobs use JavaScript libraries directly, while heavier file conversions rely on proven tools where that makes more sense.

That split helped keep each converter isolated. A PDF merge tool should not need to know anything about image compression. An HTML-to-PDF tool should not share too much logic with a WebP converter. Keeping those boundaries clear made the project easier to test and debug.

The database side is also intentionally small. Most of the complexity is not in relational modeling; it is in managing tools, content, logs, downloads, and admin settings without making the app heavy.

What I learned

The biggest lesson was that “simple product” does not mean “simple implementation.”

A good file tool has to be boring in the best way. It should accept valid files, reject bad ones clearly, process the job, clean up after itself, and give the user a result without asking them to think too much.

That means a lot of small decisions: