Processing Model

Utilavo splits its tools into two processing modes: tools that run entirely in your browser (no upload, no server contact), and tools that require server-side processing (HTTPS upload, isolated processing, immediate deletion). This page documents which tools fall into which mode, why, and what guarantees each mode provides.

Where a tool can be implemented in either mode (for example, image resizing), we choose the mode that gives the best result for the widest set of inputs. Browser-based tools avoid network round trips and keep files local; server-side tools use battle-tested native libraries that produce more reliable output across edge cases.

These tools run entirely in your browser using JavaScript and WebAssembly. Files are read from your local filesystem (or from a drag-and-drop event), processed in memory, and the result is offered as a download. No network request to Utilavo is made for the file content itself.

• PDF tools that operate on structure: merge, split, rotate, organize, watermark, page numbers, image-to-PDF, PDF-to-image
• All developer tools: JSON formatter, Base64 encoder, URL encoder, hash generator, HMAC, regex tester, color converter, encrypt/decrypt, markdown preview, JWT decoder, epoch converter, random string generator

Underlying libraries: pdf-lib for PDF structural operations, fflate for compression, browser SubtleCrypto for hashes, crypto-js for symmetric ciphers.

These tools require specialized native libraries that are impractical to ship to the browser. Files are uploaded over HTTPS, processed in an isolated working directory, streamed back, and deleted immediately.

• PDF compression, protect, unlock, repair: MuPDF performs stream and image recompression, encryption, and tolerant re-parsing
• PDF/A conversion: Ghostscript produces the PDF/A conformance output
• Document conversion (Word/Excel/PowerPoint to/from PDF): LibreOffice headless renders the input, with our own PDF-to-Word and PDF-to-Excel pipelines for the reverse direction
• HTML-to-PDF: headless Chromium via Playwright, with SSRF prevention on URL inputs
• Image processing: sharp (libvips) for resize, compress, format conversion, crop, rotate, watermark

Each request is rate-limited per IP and capped at 50 MB. Working directories are scoped to the request and removed immediately after the response is sent; a startup hook also sweeps any orphaned temporary directories left behind by killed processes.

This map is exhaustive. Every tool on the site sits in one of the two groups below. Tools in the first group make no network request that carries your file. Tools in the second group send the file to our server over HTTPS, and we say so plainly — a claim about local processing is only worth something if the opposite case is stated just as clearly.

You do not have to trust this page. Every claim in Group A is falsifiable from your own browser, and here is the exact procedure.

1. Open a Group A tool — for example Merge PDF — and let the page finish loading.
2. Open developer tools (F12 on Windows and Linux, Command-Option-I on macOS) and switch to the Network tab.
3. Clear the request log so the page load itself is out of the way, and leave recording on.
4. Select your PDF files and run the tool through to the download.
5. Read the request list. There is no POST to any /api/ path, and no request whose payload size is anywhere near the size of your files. The download is a blob: URL produced on your own machine.
6. For a stricter version of the test, load the page, then set the Network tab to offline or disconnect from the network, and run the tool anyway. It still works, because nothing on our side is involved once the code has arrived.

Now run the same check on a Group B tool such as Compress PDF. You will see one POST to /api/compress-pdf with a request body roughly the size of your file. That is the honest difference between the two groups, and seeing both halves of the test is what makes the first half mean anything.

One thing you will see in both cases is the page and its JavaScript being downloaded. That is code travelling from us to you. It is not your file travelling back.

For Group B tools, this is what the code actually does with the bytes you send.

• Most PDF routes and all image routes never touch the disk. Compress, protect, unlock and repair PDF read the upload into a buffer and hand it to MuPDF in memory; the image routes do the same with sharp. The result is returned directly in the response. No temporary file is created, so there is nothing left behind to clean up.
• Routes that shell out to LibreOffice or Ghostscript use a private temp directory. Those converters are separate processes and need real files, so the code creates a fresh directory under the system temp path — named libre-convert-, libre-profile- or gs-pdfa- plus a random suffix — writes the input there, runs the converter, reads the output back, and removes the whole directory recursively in a finally block, so the removal runs even when the conversion throws.
• A startup sweep catches anything a killed process left behind. src/instrumentation.ts runs once when the server boots. It scans the system temp directory for entries starting with those same three prefixes and deletes any that are directories with a modification time older than 30 minutes. It is a backstop for the case where the process was killed mid-request and the finally block never ran — not the primary cleanup path.
• HTML to PDF renders in a headless Chromium page that is closed afterwards. The page and its browser context are torn down in a finally block once the PDF has been produced.

There is no database of uploads, no object storage bucket, and no queue holding your file for later processing. The request handler is the entire lifecycle.

Server-side files are not retained beyond the request lifecycle. There is no persistent storage of input or output files; the process-scoped working directory is removed once the response stream completes.

Server logs record request metadata (URL path, response status, processing time, originating IP) for rate-limiting and abuse detection. Logs do not record uploaded file contents or output contents. Logs are rotated on a 30-day window.

For details on cookies, analytics, and ad delivery, see the privacy policy.

• Magic-byte validation: every uploaded file is checked against the file format's leading bytes before being passed to the underlying library
• CSRF protection: requests with a mismatched Origin header are rejected at the proxy layer
• SSRF prevention: URL-based tools (HTML-to-PDF) resolve the hostname's IP and reject private/loopback ranges
• Rate limiting: per-IP token bucket with separate tiers for image and PDF endpoints
• Resource caps: PDF page count limited to prevent DoS via high-page-count documents; watermark tile count capped for memory safety
• HTTPS-only: all file transfer is over TLS; HSTS and security headers configured at the response layer