A PDF SDK Where Your
Users' Files Never Leave the Browser
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.
<script src="https://pdfree.io/embed/sdk.js"></script>
<div id="my-widget"></div>
<script>
PDFree.create({
container: '#my-widget',
onComplete: (result) => {
// result.filename, result.size, result.blob — all local
console.log(result.filename, result.size);
}
});
</script>Browser → WebAssembly → Browser. No server in between, ever.
This isn't a mockup — try it right now:
Why this is a different kind of PDF SDK
No upload, 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.
Compliance by architecture
If a file never leaves the browser, "where is the data processed" stops being a hard question for healthcare, legal, and fintech products.
No per-request billing
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.
Built for products that can't send documents to a third-party server
- CRMs letting users merge or watermark attachments
- Healthcare portals handling patient records
- Legal / HR tools that redact before sharing
- Internal tools where "it never left the browser" is the whole pitch to security review
How this compares to what's out there today
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.
Questions developers ask first
Is this a hosted API, or does it really run client-side?
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.
How is this different from just using pdf-lib directly?
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.
Does this help with HIPAA/GDPR compliance?
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.
Will it be free, like the website?
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.
When does it ship?
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.
Get notified when it ships
No spam, no drip campaign — one email when the SDK is ready to try.