DEV Community: Pocket PDF

What in-browser PDF processing can and cannot do

Pocket PDF — Sun, 15 Nov 2026 13:22:47 +0000

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

Embedding fonts is the difference between a converted document and a broken one

Pocket PDF — Sun, 15 Nov 2026 13:18:55 +0000

One thing I learned while working on document conversion is that extracting text is only half the job.

You can successfully read every character from an EPUB, generate a PDF, and still produce a document that looks completely broken.

I ran into this problem with Urdu EPUB files.

The conversion technically completed. The PDF opened. The pages were there. But instead of readable Urdu text, some readers displayed empty boxes.

The problem wasn't the extracted text. It was the font.

Why fonts matter in a PDF

A PDF isn't simply a text file with page breaks.

It stores content positioned on a page. Text has coordinates, font information, sizes, spacing, and other properties that determine how it appears.

When a PDF uses a font that isn't embedded, the reader may need to substitute another font.

That can cause problems even with ordinary Latin text. Different fonts have different character widths, glyph shapes, and spacing metrics.

With Urdu, the problem becomes more noticeable.

Urdu uses a connected script. Characters change shape depending on their position in a word, and the correct glyph shaping and positioning are essential for readable output.

A font substitution can turn a document that should contain readable Urdu into something that looks like a collection of missing characters.

The Urdu EPUB problem

My EPUB-to-PDF converter could extract the Urdu content, but the generated PDF didn't have the right font available.

I needed a font that actually supported the script.

I chose Noto Nastaliq Urdu and changed the conversion process to embed the font in the generated PDF.

That was the important part. Having the font somewhere in the project wasn't enough. The generated document needed to carry the font information so a PDF reader could render the text correctly without depending on the reader's installed fonts.

After making that change, Urdu text could render properly instead of appearing as empty boxes.

Why embedding matters beyond the main text

The same issue can affect features that seem unrelated to font rendering.

Consider page numbers.

If a tool adds page numbers using a font that isn't available or embedded correctly, the generated output can have unexpected spacing or missing characters.

Watermarks have similar requirements. A watermark might look fine in one environment but render differently when opened on another machine.

This is why I don't treat font handling as a cosmetic detail.

It is part of producing a valid document.

What I take away from this

A successful conversion should be judged by the output, not just by whether the conversion function returned without an error.

For document tools, I now pay more attention to:

Whether the generated PDF embeds the fonts it needs.

Whether the font supports the document's character set.

Whether text positioning survives the conversion.

Whether page numbers and watermarks use reliable font handling.

Whether the result looks correct in a separate PDF reader.

A file that opens but displays empty boxes isn't a successful conversion.

This is especially important for documents containing scripts that aren't well supported by default system fonts.

I want my conversion tools to produce documents that people can actually read, not just files that pass a basic validity check.

The EPUB-to-PDF converter and the rest of my browser-based file tools are available here: https://pocketpdf.site

Auditing every tool on my site against open source, and what changed

Pocket PDF — Sun, 15 Nov 2026 13:17:29 +0000

When I started building PocketPDF, I wrote a lot of the functionality myself. That made sense initially. I wanted to understand how everything worked, avoid unnecessary dependencies, and keep the entire site running in the browser.

But there is a point where writing everything yourself stops being useful.

Some problems have already been solved by people who have spent years testing their implementations. Maintaining my own version of those solutions just means taking responsibility for bugs that I could have avoided.

I recently went through every tool on my site and compared its implementation against established open-source libraries. The goal was simple: stop maintaining code that already had a better-tested alternative.

Password strength was the first obvious change

I had a hand-written password strength calculation. It looked at things like length, character variety, numbers, and special characters.

The problem is that these rules don't tell you much about how predictable a password actually is.

Consider these two passwords:

Password123!
x7$Qp9!vLm2@Kz

The first contains uppercase letters, lowercase letters, numbers, and a special character. A basic scoring system might consider it strong.

But it is also extremely predictable.

I replaced the implementation with zxcvbn. It uses dictionaries, common password patterns, keyboard sequences, dates, repetitions, and other predictable structures to estimate password strength.

That is a much better approach than awarding points for adding another character type.

CSV parsing: Papa Parse

CSV looks simple until you encounter real-world files.

Quoted values can contain commas, fields can contain line breaks, and escaped quotation marks can cause problems for basic implementations.

Instead of maintaining my own parser, I adopted Papa Parse.

It handles the awkward cases that a simple split-based parser misses, and it means I don't need to keep fixing CSV edge cases myself.

ZIP handling: fflate

I also moved ZIP-related functionality to fflate.

It is a compact JavaScript library that supports compression and decompression without requiring a server.

For a browser-based tool collection, that matters. I can use an established implementation while keeping the processing on the client side.

HTML entities: he

HTML entity decoding is another example of something that looks easier than it is.

A few replacements might handle common entities, but a proper decoder needs to understand the actual encoding rules.

I vendored the he library rather than maintaining a collection of replacements myself.

Not everything needed a library

The audit wasn't about replacing every custom implementation with an external dependency.

Some tools have relatively specific requirements, and writing the implementation myself was still the better option.

Adding a dependency for a small operation can introduce more maintenance work than it removes. It can also increase download size and make the execution path harder to understand.

I considered a few things before adopting anything:

Does the library solve the actual problem?

Is it actively maintained?

Is it more reliable than my current implementation?

What does it add to the download size?

Can it run entirely in the browser?

Does it introduce unnecessary complexity?

If the answer wasn't convincing, I kept my own implementation.

The actual benefit

The biggest improvement wasn't a new feature users could immediately see.

It was reducing the amount of code I personally needed to maintain.

Every custom parser, scoring algorithm, or format handler is another place where an edge case can become a bug. Using a suitable library means I can spend more time fixing problems specific to my tools instead of rebuilding common functionality.

I still want the site to be lightweight, static, and browser-based. Using open-source libraries doesn't mean abandoning those goals. It means being more selective about what I build myself.

I documented the project and its tools here: https://pocketpdf.site

How I built pocketpdf.site — the file tools I always wanted

Pocket PDF — Sun, 15 Nov 2026 11:23:56 +0000

I've always wanted a simple place where I could quickly edit, convert, or manage files without having to install another application or sign up for yet another account.

Most online file tools either make you deal with unnecessary steps, limit what you can do, or put basic features behind a payment wall.

So I decided to build my own.

Meet PocketPDF — a collection of free, browser-based tools for working with PDFs, images, text, code, and audio/video files.

Why I built it

The original idea was pretty straightforward: create a website where you can open a tool, drop your file, do what you need, and get the result.

No complicated workflow. No unnecessary account creation. No software installation.

I wanted the experience to feel simple enough that anyone could use it without needing a tutorial.

But building something that looks simple on the outside isn't always simple behind the scenes.

What's inside?

PocketPDF includes tools for different types of everyday file tasks.

PDF tools cover things like merging, splitting, converting, protecting, and working with PDF documents.

Image tools help with common image editing, conversion, and optimization tasks.

Text and code tools handle various formatting, conversion, and development-related utilities.

Audio and video tools provide browser-based processing for supported media formats.

The goal isn't to build another complicated software suite. It's to make small, useful tools that solve specific problems without getting in your way.

The interesting part: making everything work in the browser

One of the things I wanted from the beginning was to keep processing client-side wherever possible.

That means the browser does the actual work instead of relying on a traditional server-side processing workflow.

It also creates some interesting technical challenges.

Different file formats require different libraries and processing approaches. Some operations are lightweight, while others need considerably more resources.

Audio and video processing is a particularly interesting challenge because of the additional processing engines involved.

Getting all of these things to work together while keeping the interface reasonably simple has been an ongoing process.

It's not perfect (and that's okay)

I don't want to present PocketPDF as some finished, flawless product.

There are still things to improve, bugs to fix, and edge cases that I haven't encountered yet.

Different browsers, file types, and devices can behave differently. Something that works perfectly on my machine might not work the same way for someone else.

That's one of the reasons I'm putting it out there.

I want people to actually use it, try different tools, and report anything that breaks or feels frustrating.

Honest feedback is much more useful to me than someone simply saying it looks good.

What's next?

I'll continue improving the existing tools, fixing reported issues, and working on the overall experience.

I also want to keep the interface straightforward. Adding more features isn't particularly useful if the website becomes harder to navigate.

PocketPDF started as a project to solve everyday file problems for myself. Now I'd like to make it useful for other people too.

If you work with files regularly, give it a try. And if something doesn't work, please let me know.

Project: https://pocketpdf.site