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