Processing Model
How Utilavo handles your files. Last reviewed: April 2026.
Overview
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.
Browser-side processing
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
- 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.
Server-side processing
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 and PDF/A: Ghostscript handles PDF object stream compression and PDF/A-1b/2b/3b conformance
- 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.
Data retention
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.
Security measures
- 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
Frequently asked questions
Are my files uploaded to your servers?
It depends on the tool. Browser-based tools (PDF merge, split, rotate, organize, watermark, page numbers; all developer tools including encrypt/decrypt and hash generators) process files locally in your browser using JavaScript and WebAssembly — files never leave your device. Server-based tools (PDF compression, document conversion to/from PDF, image format conversion, image compression and resizing, HTML-to-PDF) upload your file over HTTPS, process it in an isolated environment, return the result, and delete both the input and output immediately.
How long are server-side files retained?
Files processed server-side are deleted as soon as the response is streamed back to your browser. There is no permanent storage; temporary working files are written to a process-scoped directory that is purged on every request and again at server startup as a defensive measure. Logs do not include file contents — only request metadata (timing, status, originating IP) needed for rate limiting and abuse detection.
Can I tell whether a tool runs in the browser or on the server?
Yes. The processing-mode is documented in the section below for every category of tool. As a quick rule: if a tool requires specialized native software (image encoders, document converters, Ghostscript, headless Chromium), it runs server-side. If a tool processes structured PDF data or operates on text/encoding/hashing, it runs in your browser.
What security measures are in place for server-side processing?
Every server-side endpoint validates the uploaded file's magic bytes before passing it to the underlying library, enforces a 50 MB upload limit, applies per-IP rate limiting, blocks SSRF attacks on URL-based tools by resolving DNS and rejecting private address ranges, and rejects requests whose Origin does not match the site (CSRF defense). All file transfer is HTTPS-only.
Why does the file size limit cap at 50 MB on server-side tools?
The limit balances cost, latency, and abuse-resistance. Most documents and images people work with fit comfortably below 50 MB; raising the limit higher would primarily benefit batch/automation use cases that are better served by self-hosted libraries. The 50 MB cap applies only to server-side tools — browser-based tools are limited only by your device's available memory.
Privacy and processing questions
For privacy or data-handling questions, email [email protected]. See also our privacy policy and editorial standards.