Frequently asked questions

No. Every PDFluna tool runs entirely in your browser using JavaScript, WebAssembly, and the browser’s built-in PDF rendering library. Your files are read locally, processed locally, and saved locally. You can verify this yourself: open browser DevTools → Network before using any tool, then watch — you’ll see zero outbound requests carrying your file. The only network traffic is the initial page load and the open-source libraries (PDF.js, pdf-lib, etc.) the tool needs.

No. We can’t — the files never reach our servers in the first place. There is no “file deletion policy” on our end because there are no files on our end to delete. We don’t use file content for AI training, advertising profiling, statistical analysis, or anything else.

Yes. The strongest form of GDPR compliance is not collecting personal data in the first place, and that’s our default. We don’t require an account, we don’t process file content on our infrastructure, and the only data the site collects is anonymous analytics (page views, tool usage counts — no personal identifiers, no file content). For specific data-protection or DSAR (data subject access request) inquiries, email [email protected]. Full details in our privacy policy.

Yes — safer than most alternatives, in fact. Server-side competitors (iLovePDF, Smallpdf, ILovePDF, Adobe’s online tools) all upload your files to their infrastructure, process them there, and send the output back. For a contract, salary letter, medical scan, or ID document that’s a meaningful exposure even if their privacy policy is squeaky clean: your file briefly lives somewhere you don’t control. With PDFluna, that exposure simply doesn’t exist — the file never crosses the network.

No, and we don’t need them for the way we operate. SOC 2 / ISO 27001 audit how an organisation handles customer data on its servers. Since we don’t handle customer file data on our servers (it stays on yours), there’s nothing for those audits to examine. The closest equivalent is the open-source code itself: every library we use (PDF.js, pdf-lib, fflate, html2canvas) is publicly auditable, and your browser’s DevTools let you confirm in real time that no file leaves your device.

We use Google Analytics 4 to count anonymous page views and aggregate tool usage. No file names, no file content, no identifying information. EU visitors who reject the consent banner get cookieless Plausible analytics instead. Both are configurable in our cookie policy; opting out doesn’t affect tool functionality.

Modern browsers can do far more than render web pages. JavaScript and WebAssembly let us run real PDF libraries (PDF.js, pdf-lib) directly inside the browser tab, with full access to the file you select via the file picker or drag-drop. The file is read into the tab’s memory, processed there, and the result is offered as a download. The same technology powers Figma, Photoshop on the web, and Google Docs.

Because there’s no upload happening. The progress bars on PDFluna tools track local processing — how much of your file the in-browser library has read, encoded, or stamped — not network transfer. On a fast computer this is sometimes near-instant, which can feel suspicious if you’re used to server-side tools’ multi-second uploads, but the speed is the upside of skipping the network round trip entirely.

The first time you use a heavy tool (OCR, signing, Word-to-PDF), we lazy-load a specialised library — Tesseract.js for OCR (~14 MB), mammoth.js for Word parsing (~150 KB gzipped), and so on. These libraries cache in your browser after the first load, so the second use is instant. We deliberately don’t load them on the homepage to keep the landing-page time-to-interactive fast.

Partially. Once you’ve used a tool once and the page + libraries are in your browser cache, you can usually reload the same tool offline and it will work. We don’t currently ship a Service Worker for explicit offline use, so a reload that requires fetching new assets will fail offline. Genuine offline use is a roadmap item.

Most tools accept PDFs up to 100 MB. Format-conversion tools (Word to PDF, Excel to PDF) cap at 20 MB because parsing those formats is more memory-heavy. OCR caps at 50 MB / 50 pages because each page is rendered at 300 DPI and OCR’d, which is the slowest pipeline we ship. Specific limits are stated on each tool’s page above the dropzone.

PDF (every tool), images (JPG, PNG, HEIC, WebP — for JPG to PDF), Word documents (.docx, .rtf, .odt — for Word to PDF), spreadsheets (.xlsx, .xls, .ods, .csv, .tsv — for Excel to PDF), and signature images (PNG, JPG, GIF, WebP — for Sign PDF).

PDF (default for everything), JPG (one per page or a ZIP for multi-page via PDF to JPG), and PNG (one per page or a ZIP via PDF to PNG). We don’t produce Word, PowerPoint, or Excel from PDF — reverse conversion to flow / grid formats is genuinely hard and we don’t want to ship a tool whose output is unusable. See the blog for the full reasoning if curious.

The legacy .doc binary format from Word 97–2003 needs either Microsoft Word itself or a multi-thousand-line custom parser to convert with acceptable fidelity. We’d rather refuse cleanly than ship a tool whose output you’d compare unfavourably to other services. The 10-second workaround: open your .doc in Word or LibreOffice, File → Save As → .docx, then drop the .docx into our Word to PDF tool. Everything carries over.

Some tools yes (Merge PDF takes multiple files by design; JPG to PDF takes a batch of images). Most are one-at-a-time, intentionally: pushing five 50 MB files through the browser simultaneously would crash mid-range phones. The fastest batch workflow for compression / conversion is to run them sequentially in the same tab — the tool resets between files instantly.

Email [email protected] with the subject prefix `[Bug]` or `[Feature request]`. For bugs, including the file (if shareable) and the browser + OS speeds reproduction roughly 10×. We read every message; reply within 1–2 business days for general issues.

Every up-to-date browser: Chrome 120+, Edge 120+, Safari 17+, Firefox 120+, and the mobile equivalents (iOS Safari 17+, Android Chrome). Older versions may work for simpler tools but we don’t test against them — the WebAssembly + Pointer Events APIs we rely on are only solid on recent versions.

Yes. iOS Safari 17+ supports everything except some long-document edge cases where the browser tab runs out of memory before the rebuild finishes. As a rule, files under 30 MB are fine on phones; tablet-class devices (iPad Air 5+ or newer) handle the full 100 MB cap on most tools.

Yes — on Chrome, Firefox, Edge, and the recent Samsung Internet. Lower-end devices (4 GB RAM or less) can crash mid-process on big files for the same memory-pressure reason as on iPhone; if a tool fails on a long document, splitting first with Split PDF often gets you through.

PDF processing is CPU- and memory-intensive. A 100 MB PDF can require 300–500 MB of working memory to render and re-emit, which is more than older phones (4 GB total system RAM) can spare for a single browser tab. Workarounds: split the document first with Split PDF, lower the output DPI on rasterising tools (PDF to JPG, OCR PDF), or run on desktop.

For most tools, yes — we operate on the existing PDF byte structure rather than re-rendering, so pages keep their original vector text, embedded fonts, and image quality. Exceptions: Word to PDF, Excel to PDF, and Unlock PDF rebuild the document as image-based (visual fidelity preserved, but you lose form fields and selectable text). Each tool’s page documents the trade-off.

Our Compress PDF tool uses incremental update so original text, fonts, and signatures are preserved byte-for-byte. The space savings come from re-encoding embedded images at smaller resolutions and dropping redundant historical objects. For text-heavy PDFs the visual result is indistinguishable from the original; for image-heavy PDFs (scans, photo-based) you can pick the trade-off level.

PNG is lossless — every pixel of the rendered page is preserved exactly. JPG is lossy and produces smaller files but adds subtle ringing around sharp edges (text, line art). The S/M/L DPI presets (72 / 150 / 300) control the resolution; the JPG quality slider (60–95%) controls the compression. Same source library, different output strategy — pick by what you need.

A few of our tools (Unlock PDF and the conversion family) produce image-based output where each page is rendered to JPEG and embedded in a fresh PDF. JPEG at 200 DPI on letter paper averages 250–500 KB per page, which can be larger than the original if it was vector-only text. To shrink the result, run our Compress PDF tool on it.

Yes, and there’s no signup, no watermark, no “export limit” or “3 files per day.” The catch (such as it is): the site shows display ads on tool pages and content pages. Ad revenue covers hosting and development; that’s the entire business model. We don’t plan to introduce paid tiers, and our infrastructure costs are minimal precisely because all the heavy work runs in your browser.

Because there’s nothing for an account to store. We don’t keep your files, your history, or your settings. No account also means no password to remember and no “forgot password” flow when you come back two months later. The trade-off: no cross-device handoff (you can’t start a job on desktop and finish on phone). For occasional PDF tasks that’s the right shape; for ongoing document workflows, a paid SaaS like Adobe Acrobat is the better fit.

Yes for the current toolset. Our infrastructure costs scale with traffic but stay low because nothing happens server-side; ad revenue comfortably covers them. If the project ever needs to introduce paid tiers, it would be for new server-side features (collaborative editing, cross-device sync) and the current client-side tools would stay free.

Yes. PDFluna doesn’t claim any rights over your input files or our output. The PDF you produce is yours to use however you like — commercial work, client deliverables, archival, sharing, anything. The only restriction is the copyright of the original content (we don’t change that, and we can’t grant rights we don’t hold).

A small independent team. We built PDFluna because we needed quick PDF tools ourselves and got frustrated with the upload-to-server alternatives. The full about page has more on the why and how. For specific contact, see the contact page.