How worldofpdfs works
All 51 tools run inside your browser tab. There is no upload endpoint, no processing queue and no backend — the site is a folder of static files. This page explains how that is possible and how to check it for yourself.
There is no server to send files to
Most PDF sites work the same way: you upload a file, a server processes it, and you download the result. That model requires trusting a retention policy you cannot inspect, which is an awkward thing to do with a contract, a payslip or a scan of your passport.
This site does not have that model available to it. It is a static export — HTML, CSS and JavaScript files on a CDN, with no application server behind them. Your PDF is read straight off your disk by JavaScript, processed in memory, and handed back to you. No request carrying it is ever made, because there is nowhere for it to go.
That is a structural property rather than a promise. A privacy policy can change; an architecture with no upload endpoint cannot quietly start uploading.
What makes this possible
Two capabilities in modern browsers do the heavy lifting.
WebAssembly lets compiled code run in a web page at close to native speed. Libraries written for the desktop can be compiled once and run in a tab, which is how work that used to require a server now happens locally.
The browser's built-in PDF engine is already there — it is what displays a PDF when you open one in a tab. Driving that engine directly means page rendering, text extraction and thumbnail generation cost nothing extra to ship.
What each tool is built on
Everything here is open source, and all of it is served from this domain rather than a CDN — a third-party script would be an outbound request, which is exactly what the site claims never happens.
- pdf-lib — Reads and writes PDF structure — merging, splitting, rotating, stamping text and images onto pages.
- PDF.js — Mozilla's PDF engine, the same one Firefox uses to display PDFs. Renders pages to canvas and extracts positioned text.
- JSZip — Packages multi-file output — a folder of page images, or the EPUB container format.
- Kokoro — An 82-million-parameter text-to-speech model that runs in the browser via WebAssembly, so PDF-to-audio needs no cloud speech API.
- mammoth.js — Reads .docx into semantic HTML, which is then laid out as real text in a PDF.
- ExcelJS — Reads and writes .xlsx workbooks entirely in the browser.
- PptxGenJS — Writes PowerPoint files, used to turn rendered PDF pages into slides.
How to verify the claim yourself
You should not have to take this on trust, and you do not need to read the source to check it.
- Open developer tools, go to the Network tab, and run any tool. Watch what is requested — you will see the page's own scripts and fonts, then nothing.
- Stronger: load a tool page, disconnect from the network completely, then use it. It will work.
- We also run an automated test on every build that drives each tool through a real conversion and fails if any request crosses origins or carries a body, so this cannot regress unnoticed.
What we deliberately do not do
Converting a PDF into an editable Word document or a spreadsheet means reconstructing paragraphs, columns and table grids from a format that records only characters at coordinates. The engines that do that well have no browser equivalent, so doing it properly would mean running a server and asking you to upload.
We would rather not offer those than qualify the promise on every other page. If you need the words rather than the layout, the Extract Text tool runs locally and may be all you actually need.
Frequently asked questions
How can PDF editing work without a server?
Two things changed. Browsers gained WebAssembly, which runs compiled code at close to native speed, and every browser already ships a complete PDF rendering engine for displaying PDFs in a tab. Together those cover the work that genuinely needed a server ten years ago: parsing, rendering, rewriting and re-encoding documents.
What is WebAssembly?
A compact binary format that browsers execute directly, rather than interpreting like JavaScript. It means libraries originally written in C or Rust can run inside a web page at close to native speed. It is a normal part of every current browser, not a plugin or an extension.
How do I verify nothing is uploaded?
Open your browser's developer tools, switch to the Network tab, and use any tool. You will see the page's own scripts and fonts load, and nothing after that. Ticking "Preserve log" and disconnecting from the network entirely is an even stronger check — the tools keep working.
What happens if I lose my connection?
Nothing. Once a page has loaded there is no server involved, so the tool keeps working offline. Only the initial page load needs a connection.
Is anything stored in my browser?
No files. Documents live in memory for as long as the tab is open and are gone when you close it. There is no local database, no cache of your documents, and no account.
Do you use analytics or tracking?
There are no third-party scripts on the site at all. An automated test on every build loads each page and fails if any request goes to another host, which is what stops an analytics snippet being added by accident later.
Why do some tools take longer than others?
Because the work happens on your device rather than a server, speed depends on your hardware. Compression and page-thumbnail rendering are the heaviest, since every page has to be rendered. A desktop handles hundreds of pages comfortably; an older phone will be slower.