What's written from scratch is really "from scratch"
Take the pdf-lib folder, the brain behind nearly every PDF-based tool on MEA Tools — from merging PDFs, splitting PDFs, converting PDF to Word, filling PDF forms, down to encryption and watermarking. This folder holds nearly 37 JavaScript files with over 10,000 lines of code total, and all of it is written from scratch: a raw PDF object parser, a tokenizer, a content-stream interpreter, an xref structure rebuilder, down to a rasterizer for rendering pages into images.
That means when MEA Tools "reads" a PDF file, it's not a call to someone else's ready-made library — there's code that genuinely parses the PDF file's structure byte by byte according to the specification, written specifically for this tool's needs. The same applies across other folders: image compression logic, color conversion, QR code generation, down to hash functions — all in-house code, not a bolted-on npm package you just import.
Why bother writing it yourself?
There are several concrete reasons, not just technical pride:
- Smaller file size. General-purpose libraries are usually made generic so they can handle many cases — the consequence is a lot of irrelevant code gets dragged along. Code written specifically for your own needs can be far leaner, and that matters because all of this runs in the user's browser, not on a server with large resources.
- Full control over behavior. If there's a weird bug with a particular kind of PDF, there's no need to wait for someone else's library maintainer to release a patch — it can be dissected and fixed directly because the code genuinely belongs to us.
- No dependency that can stop being maintained. Many popular open-source libraries stop getting updates once their maintainer moves on to other things. If a tool's foundation is built on that, the risk comes along with it.
- Knowing exactly what happens to user data. Because every line of parsing is written in-house, there's no third-party "black box" processing someone's file without knowing exactly what it does inside.
But not everything is written from scratch — and that's deliberate
To keep this article honest, not just promotional: there are a few parts of MEA Tools that do use third-party libraries or models, and that's a conscious decision, not an oversight.
- Photo background removal uses an open-source AI model (U2Net) run through ONNX Runtime — a community AI inference engine, not in-house code. Rewriting an entire neural-network inference runtime from scratch is clearly beyond reasonable scope for one tool among dozens of others. The AI model file itself is hosted on MEA's own server, not riding a third-party CDN — but the engine running it is still ONNX Runtime.
- Image resolution upscaler uses the Real-ESRGAN AI model, also via ONNX Runtime, for the same reason.
- Extracting text from an image/scan (OCR) in two tools uses Tesseract.js — a mature, widely trusted open-source OCR engine. Rewriting an OCR engine from scratch is its own research project, far outside the scope of one document-conversion tool.
Here's the interesting part found right in the code itself: the only other part that was deliberately not written manually from scratch is the AES function for PDF encryption — it uses the browser's built-in Web Crypto API, not a homemade AES implementation. The reason is spelled out clearly in a code comment: AES is used for genuine security (protecting a PDF's contents from other parties), and the browser's built-in AES implementation is already rigorously audited and resistant to timing attacks — something extremely risky to rewrite manually without an equivalent security audit guarantee.
By comparison, the MD5 and RC4 hash functions in the same tools are written manually from scratch — because there, MD5/RC4 is used for legacy PDF data-format needs (not to protect data confidentiality), not for sensitive security purposes.
Write It Yourself When It Makes Sense, Use What's Proven When Security Is on the Line
The philosophy behind MEA Tools isn't "everything must be from scratch no matter the risk" — it's writing things in-house where it genuinely makes sense to fully own, and deferring to proven, audited implementations where real data security is at stake.
See All Tools →Why does this matter to you as a user?
It might sound like just a behind-the-scenes technical detail. But the impact is immediately felt: a tool written specifically for its own needs tends to run lighter, open faster, and behave more predictably — because it doesn't carry the weight of generic code that actually goes unused. And in the parts that are truly critical for your data's security, like PDF encryption, choosing to use a proven implementation is actually safer than if everything were forced to be written manually purely for the sake of consistency.
Still a work in progress
It's also worth noting: this "write from scratch" approach means every new feature takes longer than simply plugging in a ready-made library. On the PDF side specifically, this self-built pdf-lib currently covers only part of everything that can be done with a PDF file — the PDF format's world is vast, and MEA Tools hasn't stopped here. MEA Tools as a whole is still being developed and expanded, so its current feature coverage isn't a final version — it will keep growing over time.