DEV Community

Pocket PDF
Pocket PDF

Posted on

What in-browser PDF processing can and cannot do

There is a lot you can do with PDF files using JavaScript without uploading them to a server.

There are also things that sound simple but become surprisingly difficult when you try to implement them entirely in a browser.

While building PocketPDF, I ended up drawing a fairly clear line between operations that work well client-side and operations where the limitations become noticeable.

Operations that work well in the browser

The basic PDF operations are genuinely suitable for client-side processing.

Merging combines pages from multiple documents into one PDF. Splitting extracts selected pages or separates a document into individual files.

Rotating and reordering pages are also straightforward compared with more advanced document conversion.

Watermarks and page numbers can be added by drawing text or other content onto PDF pages.

Metadata editing and text extraction are similarly reasonable browser tasks.

These operations don't generally require a remote server. The browser can read the input files, process them locally, and generate the output.

Compression is more complicated

PDF compression sounds like one operation, but the actual work depends heavily on the document.

A PDF containing mostly text and vector graphics behaves differently from one containing hundreds of high-resolution photographs.

Image-heavy PDFs can consume a lot of memory during processing.

If images need to be decoded, resized, or re-encoded, the browser has to handle those operations while keeping the original document and intermediate data available.

On a large document, that can become slow and memory hungry.

I don't want to pretend that every PDF will shrink dramatically or that compression will be instant.

OCR needs a model download

OCR is another operation that requires more than a small JavaScript function.

I use Tesseract compiled to WebAssembly.

The engine is served from my own static files, and the required model data is downloaded before recognition can happen.

Once the necessary files are available, OCR runs locally in the browser.

The first use has a download cost, and processing speed depends on the device and document quality.

That is a reasonable trade-off for keeping the actual document processing client-side.

PDF to Word is where the limitations become obvious

Extracting text from a PDF is not the same as reconstructing an editable Word document.

A PDF stores positioned content. It doesn't necessarily contain the original paragraphs, tables, columns, and layout structure that existed in the source document.

A converter can extract text, but preserving the original layout is much harder.

Getting a document that looks identical in Word requires reconstructing relationships between text blocks, images, tables, and page elements.

This is the area where a proper desktop application still has a significant advantage.

I would rather be honest about that limitation than claim perfect PDF-to-Word conversion.

Background removal without AI

My background remover uses a plain edge-flood algorithm.

It starts from the image edges and identifies connected areas that match the background characteristics. Those areas can then be made transparent.

This works reasonably well for images with solid or relatively uniform backgrounds.

It doesn't perform well on complex backgrounds, detailed hair, similar foreground and background colours, or objects with complicated edges.

That limitation is deliberate.

A more capable AI background remover would require a model and, depending on how it is deployed, significant processing resources. Running that kind of model locally would also introduce a much larger download and performance cost.

I chose a smaller algorithm that works in the browser without sending the image to a server.

The practical distinction

For me, the important question isn't whether a feature can technically run in JavaScript.

It's whether the browser can run it reliably, with reasonable memory usage and an output that is actually useful.

Merging, splitting, rotating, reordering, adding watermarks, editing metadata, and extracting text are good examples of operations that fit naturally into a browser-based tool.

Large-scale document reconstruction and complex image processing are different problems.

I build the tools around what can be done well locally, rather than pretending every operation has no limitations.

You can try the tools at https://pocketpdf.site

Top comments (0)