How Reeff keeps your PDF on your device
Last updated 6 November 2026
“Files never leave your device” is easy to print on a landing page and hard to disprove from the outside. This page is the long version: which library does which job, what the browser downloads while you work, where the approach breaks down, and how to verify all of it yourself in about ninety seconds.
Two libraries, two very different jobs
Almost every PDF tool on Reeff.PDF is one of two kinds of work. Mixing them up is the usual reason a “free PDF tool” quietly destroys your text layer.
| Job | Library | What happens to the file |
|---|---|---|
| Merge, split, rotate, delete, extract, reorder, crop | pdf-lib | Rewrites the page tree and page boxes. Page content streams are copied as they are — never decoded, never re-encoded — so fonts, links and selectable text survive. |
| PDF to image; the “balanced” and “strong” compression levels | pdf.js | Renders each page onto a canvas at a chosen DPI, then exports that canvas as JPEG or PNG. This is the only path that turns text into pixels. |
| Text boxes, signatures, annotations | fabric.js + pdf-lib | Elements are drawn on an editor canvas, then written into the PDF as an overlay. The original page stays untouched underneath. |
| “Light” compression | pdf-lib | Repacks the file with object streams and leaves the metadata alone. It cannot shrink image data, so the saving is small by design. |
The distinction matters when you judge a result. If a merge produced a 40 MB file from two 20 MB files, no data was lost — the pages were copied. If a “compress” made a scan tiny and the text is no longer selectable, the pages were rasterised and the text layer is gone. Both are legitimate outcomes; only one of them is right for your document.
What the browser downloads while you work
The page itself, the interface code, and — only if the tool needs to render a page — the pdf.js library, which is loaded on demand rather than on page load. The pdf.js worker is served from pdf.reeff.app itself, not from a public CDN: the file is copied into the build next to the rest of the site, which removes a third-party dependency that could otherwise leave a tool hanging behind a blocked request.
None of those requests contain your document. Your file is read with the browser's File API into memory on your machine, and the output is handed back as a local blob that the browser turns into a download. There is no endpoint to POST to: the tools have no server component at all.
Verify it yourself
01Open the tool with DevTools visible
Press F12 (or ⌥⌘I on a Mac), switch to the Network tab, and tick “Preserve log”. Leave the filter on “All” so nothing is hidden from you.
02Clear the list, then process a file
Click the clear button, choose a PDF, and run the tool as you normally would.
03Read the request list
You will see page assets, the worker when rendering is involved, and your file appearing as a local blob. There is no multipart/form-data POST and no request whose body is your PDF.
04Cut the connection and repeat
Once the page has loaded, turn off Wi-Fi and run the tool again. It still finishes. A tool that uploads cannot do that.
Where the local approach stops
- Memory is the real ceiling, and it tracks pixels rather than megabytes. By arithmetic, one A4 page rendered at 150 DPI is about 1240 × 1754 pixels, roughly 8 MB of bitmap in memory before it becomes a JPEG. Tools that render one page at a time stay near that figure; a job that needs every page in memory at once will not.
- Scanned documents have no text layer. Selecting, searching or extracting text from them needs OCR, which needs a model far larger than a page of JavaScript — so we do not offer it rather than offer a bad version of it.
- A merge has to hold the finished document in memory before the download starts. Four hundred pages is comfortable; a two-gigabyte archive is not, on any browser.
- Nothing syncs between devices, because there is no account and no history. That is the trade: no sync, and nothing to leak.
When a local tool is the wrong tool
Local processing is the right default for a five-megabyte invoice and the wrong answer for a few jobs. Being clear about which is which costs one paragraph and saves a disappointed reader.
- You need text out of a scan. That is optical character recognition, it needs a model measured in tens of megabytes, and it does not run well in a tab. Use a desktop application or a service — and read what that service does with the file.
- The file is bigger than the machine's remaining memory. A 500 MB scan can be split locally into four parts and merged back, but nobody wants to do that twice a week; a batch job on a real machine is the honest answer then.
- The job is a hundred files a night. A browser is good at one document at a time; anything scheduled belongs on a server you control.
- You need a signature that proves the file has not changed. A drawn signature pasted into a PDF is a picture of a signature and proves nothing about who drew it — the guide on signing without a printer says exactly this, and points you at certificate-based services for the documents that have to hold up.
- You need a colour-managed proof or PDF/X for a commercial printer. Rendering in the browser produces sRGB; a print shop wants CMYK with an embedded output intent, which is a different pipeline entirely.
Why we built it this way
A server-side converter has a bandwidth bill, a storage decision and a queue, and it forces a privacy-policy paragraph that says “we delete your file after an hour”. A browser-side tool has none of those. It is also faster on a bad connection, because the file never travels.
The cost is that we cannot help you after the fact: if a tab crashes, there is no copy on our side to restore. That is why every tool leaves your original file untouched and only ever produces a new download.