Is NoUploadPDF safe?

Last updated: 10 October 2026

Security and privacy in one line: the safest file is one that never leaves your device, so no NoUploadPDF tool has an upload step. This page says what protects you, what your browser enforces, what we do not control (Google's ad code is one of those things) and how to tell us about a problem.

• No tool has an upload step
• Every page over a secure connection
• What we don't control, said plainly

Your files stay on your device

Every tool on this site is a small program that runs inside your own browser, on your phone or computer. When you add a PDF, the browser hands it to the page, the tool works on it in your device's memory, and your browser saves the new file like any other download. There is no upload step anywhere, so a copy of your file never reaches our server. That is the heart of our security, and it is a simple idea: we can't leak, sell or forget to delete a file we never received.

You don't have to take our word for it. The two checks take about a minute: watch your browser's network panel while a tool works, or switch the internet off and see the tool finish anyway. Our own test does the same for every tool and keeps a request log. How our tools work explains each step, with a picture, and the engine each tool uses. Everything below is about the parts around that idea: the rules your browser follows, what our code does, and the things no website can promise.

What your browser enforces

Every page we send comes with a few short instructions called response headers. Your browser reads them before it shows the page, and then follows them itself, whatever any script on the page tries to do. They are rules for the browser, so they keep working even if a script on the page misbehaves. This table lists each security header the site sends and what it tells your browser:

The most important one is the Content Security Policy, a list of the places a page may load things from and send data to. Think of it as a second lock. The first lock is that no tool has an upload step. The second makes your browser refuse requests to any site that is not on the list, which is meant to catch a mistake in our own code, or a script that has no business being on the page. Every site the policy allows is listed on the proof page, made from the policy itself, so the list can't fall behind what the site sends.

You can read these headers yourself:

1. On a computer, open any page of this site in Chrome or Edge and press F12.
2. Choose the Network tab and reload the page.
3. Click the first request in the list, the page's own address, and look under Response Headers.

If you are comfortable with a terminal, curl -I https://nouploadpdf.online/ prints the same headers.

What our code does and doesn't do

• No upload step. No tool has one, and our code never gives your files to the ad code. The tools have no upload form and no code that sends a file anywhere, and the policy above says no form on our pages may send what is typed into it.
• No accounts, no cookies of our own, and our code never stores your files. There is no sign-up and no login, so there is no list of passwords for us to protect. Our code keeps one small thing in your browser's own storage on your device: the names of the last few tools you opened, for "Your recent tools" in the menu and on the home page. It is never sent anywhere, and the Clear button next to it deletes it. We searched the site's own scripts, engines, pdf.js and HarfBuzz on 10 October 2026 and found no other use of cookies, localStorage, sessionStorage or IndexedDB. The site has no service worker. Google's ad code is different: it may set cookies, as the section on ads below says.
• A PDF's own scripts never run here. Some PDFs carry small programs that certain readers run. We use pdf.js, Mozilla's PDF reader, to draw pages, and we left its script runner out on purpose. XFA forms, a rare kind of form that can carry scripts, are switched off. Our own engines read and write the structure of a PDF (pages, pictures, fonts, locks) and have no script runner at all.
• Passwords stay in the page. A password you type in Unlock PDF or Protect PDF is used in the page, in a background worker of your browser, to open or add the lock. It is never uploaded, because nothing in the tool uploads. Unlock PDF never guesses a password: a file that needs one to open needs the one you know.
• Everything the tools run comes from this site. The scripts, the engines, pdf.js, HarfBuzz and the fonts are files on this site, and the policy lets the page run scripts only from this site and from Google's ad hosts. A tool never loads anything from Google or any other site while you work. Google's ad code is the only outside code on a page.
• Our own copy of every library. We keep each library we use at a fixed version and serve it ourselves, instead of loading it from a public library host while you work. A change on someone else's server can't change the tools that run on your device.
• Libraries with open licences we have read. The engines are our own Rust code built on open-source crates by other people. Every one is listed with its licence in the Rust crates list, and the build stops when that list is out of date. We use only permissive licences such as MIT, Apache-2.0, BSD, ISC and Zlib, and open font licences such as the SIL Open Font License for fonts.

Google's ad code: what we don't control

NoUploadPDF is free because Google's ads pay for it. To show them, our pages load Google AdSense's ad code. It is Google's code, not ours, and it is the one part of a page we don't write and can't fully see into, so here it is in plain words.

• Where it runs. On every page except the privacy policy and the error page, which load no ad code at all. No tool uses it.
• What it knows. It runs in your browser like the ads on any website, and it sends Google information such as the page address, your IP address and details about your browser. Google may use cookies to show and measure ads. The privacy policy says what we saw it set in our own test.
• What our code gives it. Our code never gives your files to the ad code. We also test this with Google's real ad code on the page, using a stand-in publisher ID so no ad views are counted: the test fails if any request made while a tool works on a file carries 4 KB or more. It is described under what our own test sees.
• What we can't promise. We can't open Google's code and vouch for it line by line, because it is Google's and Google changes it often. What we can do is limit where the page may send data, which the policy does, and run a test with the real ad code, which is described under what our own test sees.
• Your choice. Visitors in the European Economic Area, the United Kingdom and Switzerland are asked for consent through Google's own message before Google uses cookies or personal data for personalised ads. Anyone can opt out of personalised ads in Google's Ads Settings or at aboutads.info. The privacy policy has the full wording.

Our server

The site is a set of ready-made files, sent out by an ordinary web server. We have no program on the server that accepts a file, because no tool needs one. The server's job is to send you the page and the tool.

Every page travels over an encrypted https connection. If someone types an old http:// address, the server sends them on to the https one, and the Strict-Transport-Security header in the table above asks your browser to keep using https for this site for a year after each visit.

Like most web servers, ours may keep short technical records of page requests, such as IP address, date and time, the page requested and browser type. They are used only to keep the site secure and working, and they never include your files. Pages are checked with the server on every visit, so when we fix something you get the fixed page the next time you open it. Your browser keeps the engines and scripts for next time, and they get a new name whenever they change.

What is outside our control

Some things are outside what any website controls. We would rather tell you than leave you to find out:

• Browser extensions. Extensions you have installed can see the pages you open, here as on any site. If one of them reads every page, a tool's page is no exception. Most browsers switch extensions off in a private window unless you allow them there.
• Your device and where you save. If a phone or computer already has harmful software on it, or someone else uses it after you, no website can protect a file there. A saved file is only as safe as the folder it sits in. On a shared device, delete files you no longer need from your Downloads, and empty the bin too.
• Look-alike sites. Other sites have names like ours, and everything on these pages is about nouploadpdf.online only. If you are unsure where you are, look at the address bar. About us says which sites we are not affiliated with.
• What our tests don't cover, and outside audits. We test through independent tests and through our own agentic testing workflow: our testing agents use every tool in headless Chromium at phone and computer screen sizes, check the files it makes, and run our automated test suites. These tests don't cover Safari or Firefox. No outside company has audited NoUploadPDF or certified it. What our tests don't cover is listed in full.
• A weak password on a locked PDF. Protect PDF puts an AES 256-bit lock on your file, and a lock is only as strong as its password. A short or common password can still be guessed. The Protect PDF guide says how long a password held out against our own code, and what makes one last.

How to report a security problem

If you think you have found a security problem, please email info@nouploadpdf.online. You don't need to be an expert. It helps if you tell us:

• the address of the page, as it shows in your browser's address bar,
• what you saw, and what you expected to see,
• your browser and your device, and
• the steps that show the problem again.

Please don't attach a file with private details. NoUploadPDF never needs your files to work, and a description is almost always enough. If you think we need a file to see the problem, say so in your first message and leave it out until we reply.

The same address is in our security.txt file, the standard place (RFC 9116) where people who look for security problems check first. It is renewed each time we publish the site.

We reply to a security report within 7 days. We don't run a bounty programme. NoUploadPDF is run by one person, and a clear report is the best help in getting a problem fixed. For a question about a tool that is not about security, our contact page is the place.

Keep reading

• About us: who runs NoUploadPDF and why.
• How our tools work: what happens to your file, step by step.
• How we prove no upload: two checks you can do yourself in a minute.
• How we test: how we measure the results we quote, and what our tests don't cover.
• Privacy policy: what we collect, and how Google's ads use cookies.