I Audited the Code of All 28 BuzzKit Tools for File Uploads. Here Is What I Found

Every tool on BuzzKit says the same thing: your files stay on your device. That is an easy sentence to write and a hard one to prove. So on October 7, 2026, I audited the code behind all 28 tool pages to see whether anything in it can send a file anywhere. This post is what the audit found, including the parts that are not flattering.

The short version: none of the 28 tools contains code that uploads your file. But the audit also turned up three things you should know about, and one of them is a weakness I would rather flag than hide.

Why audit your own tools?

Most free converters ask you to take their privacy claims on trust. In The Dangerous Truth About Free File Converters I wrote about why that is risky, and in How to Check If a Website Uploads Your Files I showed how you can test any site yourself with browser DevTools. A site that tells you to verify other tools should be willing to be verified itself, so this is that test, applied to BuzzKit.

How the audit worked

This is a static code audit, which means reading the code instead of watching it run. For each of the 28 tool pages I did the following:

1. Loaded the live page and listed every script it loads, split into BuzzKit’s own scripts and scripts from other hosts.
2. Downloaded every one of BuzzKit’s own scripts for that page, then searched the page and its scripts for every browser feature that can send data off the device: fetch(), XMLHttpRequest, navigator.sendBeacon, new FormData (the usual way to attach a file to a request) and new WebSocket.
3. Scanned all 66 HTML, JavaScript and PHP files in the BuzzKit theme folder for the same calls and for every outside web address they mention.
4. Measured page weight and response time for each tool page.

A search like this works on minified code too, because the browser features have fixed names that cannot be hidden. What it cannot do is watch the tools run, so I list its limits further down.

The headline result

Across all 28 tool pages the search for upload mechanisms came back the same way every time:

• XMLHttpRequest: 0 matches on all 28 pages.
• sendBeacon: 0 matches on all 28 pages.
• FormData: 0 matches on all 28 pages. Without it, a page has no standard way to package a file for sending.
• WebSocket: 0 matches on all 28 pages.
• fetch(): exactly 1 match on every page, and it is always the same one. It belongs to the thumbs-up and thumbs-down feedback widget.

That one fetch() call sends a POST request to BuzzKit’s own address /wp-json/buzzkit/v1/vote. Its body contains two fields, the tool’s name and the vote. No file, file name or file content is part of it. It runs only when you press a feedback button.

All 28 tools, what powers them and what they load

Here is every tool page, what does the processing, where any extra code comes from, and how heavy the page is. The page size is the HTML only. The script size is BuzzKit’s own scripts for that page, not the extra engines listed in the third column.

The tools fall into four groups. 12 use ffmpeg compiled to WebAssembly (the audio and video tools). 5 use pdf-lib (Merge PDF, Split PDF, Image to PDF, Compress PDF and PDF to Image), and 2 of those, Compress PDF and PDF to Image, also use pdf.js to render pages. 1 uses gif.js (the GIF Maker). The remaining 10 (the image tools) use only the browser’s own Canvas features and load no extra engine.

Page weight and speed

The page HTML ranges from 20.9 KB to 30.6 KB, with a median of 22.2 KB. BuzzKit’s own scripts run from 17 KB to 26 KB per page. Measured from the web server itself, with caching bypassed, the pages responded in 232 to 684 milliseconds, with a median of 257 ms. Those timings come from the server making a request to itself, so they leave out the distance to you and your connection. Treat them as a best case, not a promise.

Three things the audit turned up

1. The audio, video and PDF engines come from a third-party CDN

This is the finding I would most like to change. The ffmpeg engine, pdf-lib and pdf.js are not stored on BuzzKit’s server. The first time you use one of those tools, your browser downloads the engine from unpkg.com, a public code-hosting service. That affects 12 audio and video tools and 5 PDF tools, 17 of the 28.

Two things follow from this. First, it is a download, not an upload: your file is not sent to unpkg. But unpkg does see a request from your browser, including your IP address, when the engine is fetched. Second, the tools depend on a service I do not control. If that service were slow, down or compromised, those tools would be affected. The fix is to host the engine files on BuzzKit’s own server, which removes the outside dependency entirely. I am flagging this as an open weakness instead of presenting a clean sheet.

It also changes how you should run the offline test. If you switch your browser to offline mode before the engine has loaded, these tools will fail for a reason unrelated to privacy. Load the page, run one operation so the engine downloads, then go offline and run another.

2. Ads and analytics scripts load on every tool page

Google’s tag script and the AdSense script load on all 28 of the 28 pages. These are third-party scripts and they are outside the scope of a search of BuzzKit’s own code. Standard behavior for such scripts is to receive things like the page address, your browser details and your IP address. They do not read the contents of a file you drop into a tool, and nothing in BuzzKit’s code passes a file to them, but I cannot make guarantees about code I do not write. One detail from the page source: the analytics consent defaults are set to denied before the Google tag loads, for ads storage, ad user data, ad personalization and analytics storage.

3. There is dormant code that talks to Google Drive and Dropbox

The theme folder contains a file called cloud-integration.js, written to let you import a file from Google Drive or Dropbox. Its two fetch() calls download the file you pick into your browser. None of the 28 tool pages loads it, and its own comments say it needs credentials that have not been set up. If it is ever switched on, I will document it here, because it would add calls to Google and Dropbox that today do not exist.

What this audit cannot tell you

• It reads code, it does not watch behavior. A static search can miss code that builds a network call in an unusual way at run time. The offline test and the Network tab check behavior directly, and you should still run them.
• It does not cover third-party scripts. Google’s scripts and the engines from unpkg are code I did not write and did not audit line by line.
• It does not cover the server side. I confirmed what the vote request sends. I did not review everything the server does with it.
• It is a snapshot. The code was scanned on October 7, 2026. Tools change, and a scan from one day does not cover tomorrow’s edits.

How to check this yourself

You do not need to trust any of this. Open the Video Compressor, Merge PDF or Image Converter, press F12, open the Network tab, and process a file. Look for any request that is large, close to your file size, or sent to a server. Then repeat it with the network set to offline. The full walkthrough is in How to Check If a Website Uploads Your Files.

What I would change next

1. Host the engines on BuzzKit’s own server so no tool needs unpkg, which would leave only the gif.js worker on a CDN.
2. Remove or document the dormant cloud code so the theme has no calls to outside services that are not in use.
3. Repeat this audit after any significant change, and publish the date.

Frequently asked questions

Do BuzzKit tools upload my files?

The code of all 28 tool pages contains no upload mechanism. The only request BuzzKit’s own code makes is the optional feedback vote, which carries a tool name and a vote.

Why does a browser tool need to download anything at all?

Heavy tasks such as video compression use an engine, ffmpeg, that is compiled to run in the browser. The engine has to be downloaded before it can work. Downloading code to your device is different from sending your file out.

Does unpkg see my files?

No. Your browser fetches the engine files from unpkg, and unpkg receives a normal web request for those files. Your own files are never part of that request.

Is a static audit enough to prove a tool is private?

No single check is. This audit shows what the code is able to do, and the Network tab and offline test show what it actually does. Using both is the strongest approach.

← Back to Blog