How we test

Last updated: 10 October 2026

Every NoUploadPDF tool is tested before it goes live, and every test result on the tool pages comes from our own tests. We test through independent tests and through our own agentic testing workflow. This page says how, how a number gets onto a page, and what our tests don't cover.

• Real files, checked in other PDF readers
• Phone and computer screen sizes
• Only numbers we measured

Two kinds of testing

Independent tests. An independent QA report of 8 October 2026 went through the tool pages and listed what it found. We fixed the problems it found and wrote a test for each fix, as the part on people and fixes explains.

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. The workflow has these steps:

1. Build. Each tool is built on its own branch, and comes with its own tests.
2. Verify. A testing agent uses the page the way a first-time visitor would, checks that the files it makes are valid, and runs all the checks listed below. If something fails, the tool goes back to be fixed and is verified again.
3. Review. A second step looks at wording, search results and the paths people take through the site, and writes questions for the owner. The owner decides what changes.
4. Publish and compare. Only work that has passed is published. After publishing, the live files are compared byte for byte with the build that was tested, using plain downloads and no browser.

The files we test with

Real documents are messier than made-up ones, so we start with real ones: research papers, a 117-page maths textbook with bookmarks and links, scanned contracts, application forms with fields to fill in, and Word books with tables and pictures. These are the papers people actually bring to a PDF tool.

Then we make the hard cases ourselves, so we can ask for exactly the trouble we want to see:

• scans in colour and in grey, photos, CMYK pictures, transparency, repeated pictures, forms, and scans of many pages at 300 dpi;
• damaged and cut-off files, including damaged JPG photos for JPG to PDF;
• locked PDFs in every kind of lock we know of, from the old 40-bit locks to AES 256-bit, and locks that only restrict printing or copying;
• Word documents in Hindi, Tamil and other Indian scripts, for Word to PDF.

For big files we use big scans: one of 47.8 MB with 42 pages, one of 455 MB with 400 pages and one of 1.11 GB with 1,000 pages. Many guides name the files behind their numbers.

The browser and screen sizes

We test in Chromium, the open-source browser that Chrome and Edge are built on. A program called Playwright drives it: it opens the page, clicks, adds files and records what happens. The browser runs headless, which means without a visible window. Several of our guides name the setup their numbers come from, such as Chromium 141 on a Linux computer with 4 processor cores and 16 GB of memory. Not every guide does yet.

A computer's screen is tested at 1280 by 900 pixels. A phone-sized screen is tested at 390 by 844, with touch turned on. Two checks go further:

• The layout check opens a page at 8 widths from 320 to 1280 pixels in light mode, and at 390 and 1280 in dark mode. It fails on any sideways scrolling, any table that does not fit a phone-sized screen and any error on the page.
• The screenshot check takes pictures at 8 screen sizes, from 360 by 740 up to 2560 by 1440.

Our tests never count as ad views. The test server answers Google's ad loader with an empty script, so our automated tests never load Google's ads. One separate test does load Google's real ad code, with a stand-in publisher ID so no ad views are counted. It checks that our policy still lets the ad code work and that no request carries 4 KB or more while a tool works on a file.

What our tests check

• The saved file opens in other PDF software and keeps what it should. We open results in programs other than ours, which ones depending on the tool: PDFium (the reader inside Chrome), pypdf, Poppler, qpdf, whose check looks for damage, and for some tools MuPDF. We compare the page count, the text, and the notes and links on the pages, and where a tool could change how a page looks, we measure how much it changed. Page sizes are checked against the size we said. The Word files PDF to Word makes are read back with python-docx.
• Nothing is uploaded, and the tool works with the network off. For each tool, our test switches the network off, runs the tool on its built-in sample and lists every request the page made. It fails if any request sent data, or if the tool needed the network to do its work. On 9 October 2026 every tool but Word to PDF finished with the network off. Word to PDF needs the internet the first time, to download its converter and fonts from this site. What our own test sees shows the log.
• Files can be removed, and a finished result is not thrown away. The tests check that each file has an × in every state, that two or more files get Clear all, and that a change of options never redoes or discards a finished file without asking: the tool offers "Redo at" the new setting instead. They also check that signals stay calm, with no alarm red and no warning triangle for normal outcomes. The wording of messages was checked again wherever an outside check found it unclear.
• The keyboard works, and the automatic accessibility checks pass. Tab reaches the Choose button, and Enter opens the file chooser. axe-core, an accessibility checker, finds no WCAG 2.0, 2.1 or 2.2 level A or AA problem on our tool pages. Small labels are at least 12.5 px, and on a touch screen the buttons are at least 40 px.
• Nothing scrolls sideways, in light or dark mode, as the layout check above makes sure.
• The build itself refuses a page that breaks our rules. The site will not build if a tool guide has fewer than 2,500 words or fewer than 15 questions, if a Quick fact has a number that is missing from its test, if a page uses privacy wording that stopped being true once Google's ad code arrived, if a search title is over 60 characters, if the structured data differs from the page or carries a rating that did not come from visitors, or if a first visit is heavier than the page says.

People and fixes

A program does not get confused the way a person does. On 9 October 2026, Vemulapalli Rajkumar, who runs the site, went through the tool pages as an ordinary visitor would and wrote down what he found. Those notes are kept with our other test reports.

The independent QA report of 8 October 2026 was handled the same way: we fixed the problems it found and wrote a test for each fix. One thing it asked for, watermark words in Hindi and other scripts, is still to come. One example of a fix is that after you change a compression level, a finished file now offers "Redo at" the new level instead of quietly handing back the old result.

How we measure the numbers on our pages

Every test result on a tool page, such as a file size, a time or the memory used, comes from our own tests, with its context so you can judge it: the file and the result, and in many guides the browser and the computer too. A few numbers are worked out from a measured one, such as how long a password would hold out against a guessing rate we measured, and the page says so. Here is a measured result from the proof page: in our offline test the compressor took its built-in sample scan from 10.1 MB to 621 KB. That sentence names a file, a result and a test. A number without those would not be worth quoting.

• Quick facts link to their proof. Under each tool, the Quick facts show three to five numbers, and each links to the part of the guide that shows the test behind it. The site will not build if a fact's number is missing from that test.
• Times and memory are from our test computer. Your phone or computer may be faster or slower, and phones are usually slower. Treat our times as a guide, not a promise.
• We invent no ratings, reviews or user counts. The build refuses any review, and any rating that did not come from real visitors.

What our tests don't cover

• Safari, Firefox and other browsers. Our automated tests don't run in them. The two checks on how we prove it work in any browser, so you can run them in yours.
• Screen readers with real users. Our accessibility checks are automatic (axe-core) and keyboard tests. They don't include people who use screen readers.
• Every PDF ever made. Some files may not work, especially damaged or unusual ones. If one of yours does not, we want to know.

We write this list so you can see where our evidence stops. When our testing changes, this page changes, and the date at the top shows when. No outside company has audited NoUploadPDF or certified it, as security also says.

Found a file that doesn't work?

Tell us on our contact page: the tool, your browser and device, the file's size and what happened. Please don't send a file with private details. A description is usually enough to start, and if we need the file, we will ask.

Keep reading

• About us: who runs NoUploadPDF and why.
• How our tools work: what happens to your file, step by step.
• Security: what keeps your files safe, and what we don't control.
• How we prove no upload: two checks you can do yourself in a minute.
• Privacy policy: what we collect, and how Google's ads use cookies.