Every PDF API on the market works the same way: your users' documents get uploaded to someone else's server. PDFree's engine has processed files entirely client-side since day one — we're now shaping a high-level SDK so any product can embed that same guarantee, with none of the low-level plumbing.
import { PDFree } from '@pdfree/sdk';
// Runs in your user's browser. Nothing is uploaded.
const merged = await PDFree.merge(files);
const smaller = await PDFree.compress(file);
const redacted = await PDFree.redact(file, areas);Browser → WebAssembly → Browser. No server in between, ever.
Most PDF APIs — however good — receive your users' files on a server by design. This one doesn't have a server in the file's path at all.
If a file never leaves the browser, "where is the data processed" stops being a hard question for healthcare, legal, and fintech products.
Processing runs on your user's device, not on infrastructure you pay for by the call. Pricing is about the SDK license, not metered compute.
There's no shortage of PDF tooling for developers — the honest comparison is about where each one sits, not which is "best."
| Approach | Where files are processed | Level | Pricing shape |
|---|---|---|---|
| PDFree SDK | Browser only — never leaves the device | High-level (merge/compress/redact as one call) | SDK license, no per-request metering |
| pdf-lib (open source) | Browser or Node — genuinely no server required | Low-level — you assemble merge/compress/redact yourself | Free, MIT-licensed |
| Nutrient / PSPDFKit Web SDK | Client-side deployment is one option among several (also cloud/on-prem) | Full document viewer/editor platform | Component-based annual license, custom quote |
| pdfRest self-hosted container | Your own server/Docker — stays in your infra, but is still a server | Full HTTP API (SOC2/HIPAA/GDPR audited) | Self-hosted licensing |
Based on public pricing/docs pages as of 2026; verify current details directly with each vendor before deciding. pdf-lib is free and open source — the gap it leaves is the high-level, ready-to-call operations layer PDFree SDK is aiming to be.
Client-side only. There's no endpoint that receives your users' files — the SDK ships WebAssembly/JS that runs in the browser tab, the same engine already powering pdfree.io's own tools.
pdf-lib is a great low-level library, but it doesn't ship ready-made compress/watermark/redact operations — teams build and maintain that layer themselves. PDFree SDK aims to be the finished, high-level version of that layer.
If a file never leaves the browser, "does this vendor receive PHI/personal data" is off the table for that step of your pipeline. It doesn't replace a full compliance review of your own product, but it removes one entire category of risk.
pdfree.io stays free for individual use. The SDK is being scoped as a licensed product for teams embedding it in their own software — exact pricing isn't set yet, which is part of why this page exists.
There's no date yet — this page is the first real signal-gathering step. Join the waitlist below and tell us what you'd build; that shapes what gets built first.
No spam, no drip campaign — one email when the SDK is ready to try.