Compress your PDF — without uploading it.
Aadhaar scans, signed contracts, property deeds — never leave your device. Type your exact KB target, get the file back, in seconds.
Your file stays on your device. Compressed locally via WebAssembly.
Verify it yourselfDrop your PDF here
or click to browse · max 50MB · stays on your device
What exactly happens to your file?
Click to see the full data path. No surprises.
What exactly happens to your file?
Click to see the full data path. No surprises.
- 1
You drop the file
Browser reads the file from your local disk into a `File` / `Blob` JavaScript object. This is the standard browser File API — same as any web upload form, except we stop there.
No upload here.
Other tools insert an upload step at this point. We don't — there is no server endpoint in our codebase that receives file content.
- 2
Browser compresses it
WebAssembly modules + Canvas APIs run on your device. For PDFs we use pdfjs-dist + pdf-lib (both ~3MB lazy-loaded once). For images we use the browser's built-in JPEG/PNG/WebP encoders + a libheif fallback for older HEIC support. All execution happens in your browser process.
- 3
You download the result
The compressed blob lives in browser memory. When you click Download, the browser triggers a local file save. No HTTP request goes out — the only network calls during a compression are loading the engine (cached on first use).
Verify any of this for yourself: open DevTools (⌘ ⌥ I on Mac · Ctrl Shift I on Windows / Linux), open the Network tab, then run a compression. You'll see the engine load on first use, then nothing during the actual compression. We have a full live demo at /privacy/verify.
You just compressed without uploading.
Here's what you didn't do — and why it matters.
iLovePDF, SmallPDF, Adobe Acrobat Online uploaded your PDF
Their server received your file, compressed it there, and held it temporarily. You had to trust their privacy policy and security on every step.
FormReady processed your PDF locally
The compression engine ran in your browser via WebAssembly. Your PDF never touched any FormReady server — and you can verify this in your own DevTools Network tab.
Our promise — verifiable
Four architectural commitments. Every one provable.
No upload endpoint
Our codebase contains zero server routes that receive file content. Architectural, not policy.
Audit the routesOpen-source compression engine
Fork it, audit it, run it offline. We open-source the compression logic under MIT.
View on GitHubNo file fingerprinting
We don't log file names, hashes, sizes, or any derived metadata. We log nothing about your file.
Read the privacy policySelf-verifiable
Every claim above is checkable by you in 30 seconds, in any modern browser, with the built-in DevTools.
Run the live demoCommon use cases
What people compress with this tool
Real scenarios with their typical KB targets. Click a guide if it matches what you're doing.
Property registration
Sale deed, agreement, ID copies for state portals
500 KB
SSC application
PDF supporting docs upload
100 KB
Open guideVisa supporting docs
US, UK, Schengen, Canada embassies
200 KB
Bank statement upload
KYC, loan applications, ITR portals
1 MB
College admission form
CUET, university portals, scholarship
200 KB
Job portal upload
Naukri, Monster, govt job boards
500 KB
FAQ
Real questions from real users.
You really can't see my PDF?
Correct. The compression engine runs entirely in your browser via WebAssembly and Canvas APIs. There is no server endpoint in our codebase that receives file content. You can verify in 30 seconds: open DevTools → Network tab and watch a compression run. Zero new requests appear during compression. We have a live demo at /privacy/verify.
Is this safer than iLovePDF for sensitive documents?
Yes — fundamentally. iLovePDF and similar tools upload your PDF to their server, compress it there, and send the result back. Their privacy policy controls what happens with your file in transit and on disk. With FormReady, the file never leaves your browser. There is no privacy policy you have to trust about what happens to your file because nothing happens to your file outside your device.
How does the "exact KB" target work?
You type a number (e.g., 100KB). Our engine tries progressively stronger compression strategies (structural, then page rasterization at decreasing quality) and stops as soon as the output is at or under your target. If we genuinely can't hit the target without making text unreadable, we stop at the smallest legible size and tell you.
What's the maximum file size?
Up to 50MB input. Larger files risk running out of browser memory on mid-range Android phones — we may add server-assisted compression for Pro users in a future release.
My PDF is password-protected. What now?
Browser PDF libraries can't process encrypted PDFs. Unlock the PDF first (your PDF reader's "Save as" → uncheck password is the simplest path), then compress.
Will the compressed PDF still have selectable text?
For very small targets (where structural compression isn't enough), we rasterize each page to JPEG and rebuild the PDF. This gives the smallest sizes but text becomes raster (not selectable). For text-heavy PDFs where you need selectability, choose a larger target so structural compression alone hits it.