“Runs in your browser” is easy to write on a product page. We wanted to check it the only way that actually means anything: recording the literal network requests a browser makes while using the tool, not reading the tool’s own description of itself.
What we tested
Three tools, chosen to span different processing categories rather than testing the same thing three times:
- Merge PDF — combining two generated PDFs (2 pages + 3 pages, no real documents)
- PNG to JPG — converting one generated PNG image (a synthetic color-noise pattern, not a real photo)
- Compress PDF — covered in detail in our earlier compression test; referenced here for cross-tool comparison
For Merge PDF and PNG to JPG, we used a scripted browser session with a network-request listener attached before the file was ever selected, so every request from upload through result was captured — not sampled or summarized after the fact.
What we found: Merge PDF
We merged two generated PDFs (2 pages and 3 pages). Zero network requests were recorded from file selection through the “Task Complete!” result. The tool reported combining 2 input files into a 5-page, 35.57 KB output — page counts add up exactly as expected (2 + 3 = 5), which is at least consistent with the files actually being processed rather than some placeholder result.
What we found: PNG to JPG
We converted one generated 335.12 KB PNG image. The only network-layer event recorded during conversion was a single blob: URL reference — not a request to any server. A blob: URL is how a browser hands itself a reference to data already sitting in its own memory; it never leaves the browser process, unlike an HTTP request. The tool reported the real result: original 335.12 KB, output 161.3 KB, “Smaller by 51.9%,” dimensions unchanged (600×400 → 600×400) — a substantiated size reduction, unlike what we found when testing PDF compression, where reductions were much rarer. That contrast is itself informative: image format conversion to a lossy codec (JPEG) reliably shrinks file size in a way that PDF structural compression often doesn’t.
What this does and doesn’t show
Across both tools tested here, we recorded no requests that resembled a file upload — no POST/PUT carrying file bytes, no request to any endpoint outside the page’s own static assets. That’s consistent with the “runs in your browser” claim on both tool pages.
This is a snapshot, not a standing guarantee. We tested two tools, on one day, on desktop Chromium, in production. We didn’t test every tool NexKit offers, we didn’t test mobile browsers, and a future release of either tool could change how it processes files. If you need certainty for a specific sensitive file, verify it yourself with your browser’s own developer tools — that’s the same method we used here, and it doesn’t require trusting our report.
Known limitations
- Only two tools were traced in this specific test (Merge PDF, PNG to JPG); Compress PDF’s network behavior was covered separately.
- Fixtures were small, synthetic files — we did not test large files or files near either tool’s stated size limit in this round.
- ”Zero requests observed” describes this test run, not a permanent property of the tools.
Bottom line
For the two tools and files tested here, no file-upload-style network request occurred at any point — the processing genuinely happened in the browser, not on a server we could observe. If a specific tool ever needs to change that (some workflows genuinely can’t run entirely client-side), NexKit’s own labeling convention is to mark it “Temporary server processing” before you start — see How NexKit Works for what that distinction means in practice.
Related tools: Merge PDF · PNG to JPG · Full methodology