Privacy claims are easy to make. A company can put “your files never leave your device” anywhere on their site and face no immediate consequence if the claim is wrong. The typical user has no way to check. Most people accept the claim, proceed, and hope it is true.
This site makes claims like that. This post is about how to verify them yourself. Not trust them — verify them. The tools are in your browser already, and the process takes about five minutes per claim. If a claim does not hold up to inspection, that inspection result is the truth, and the claim text is the problem. We will walk through each major claim on this site, what it means in plain language, and exactly what to check.
Claim: “Your files never leave your browser”
This claim applies to the file-processing tools: PDF to image, image to PDF, image compression, format conversion. The claim is that when you drop a file onto one of these tools, the file does not get uploaded to a server.
How to check it:Open any of the file tools. Before dropping a file, open your browser’s developer tools. In Chrome, Edge, or Brave, press Cmd+Option+I on Mac or Ctrl+Shift+I on Windows and Linux. Click the Network tab. Click the clear button (a circle with a line through it) to empty the request list. Now drop a file onto the tool and watch the Network tab while the conversion runs.
What you will not see: a request that has a payload size similar to your file size. If a file upload happened, the Network tab would show a POST or PUT request with a large request body. That request does not appear. What you will see is the conversion completing and the download appearing, with no new outbound requests in the list.
What the Network tab will show instead: The requests from the initial page load. Possibly a PostHog analytics event indicating that the tool was used (a small JSON payload with no file contents). Nothing else.
This check is definitive. HTTP requests cannot be hidden from the browser’s own Network tab. If no upload request appears, no upload happened.
Claim: “AI runs on your computer”
This applies to the AI tools: the summarizer, writing assistants, the cover letter tool, and others. The claim is that when you enter text and click the button, your text is processed by a language model running in your browser tab, not by a remote API.
How to check it: Open an AI tool. Open the Network tab in developer tools and clear it. Type a prompt and submit it. Watch the Network tab during generation.
What you will not see: a request to an AI API endpoint (api.openai.com, api.anthropic.com, or any similar domain). If your text were being sent to a cloud AI service, you would see an outbound POST request to that service. You would also see the response arriving as the AI generated it, either as a stream or as a complete response.
What you will see instead: nothing new in the Network tab, while the text appears on the page one token at a time. The generation is happening locally. The network is idle. If you want extra confirmation, you can run the same test with airplane mode enabled — after visiting the page once to cache it — and the AI will still work.
A note about the model download: The first time you visit an AI tool, the model file downloads. This is a large file — several hundred megabytes. That download is visible in the Network tab. That is expected; the model has to arrive somehow. After the download, the model is cached in your browser. On subsequent visits, the model loads from cache and no download occurs. The generation after that involves no outbound requests.
Claim: “No personal information is collected”
This claim is narrower than it sounds. It refers to personal information in the files you process and the prompts you send to AI tools. It does not mean the site has zero analytics, because it does have analytics. It means the analytics do not receive the contents of your files or your prompts.
Three third-party services load on this site. Here is what each one receives:
PostHog analytics:Records page views and tool usage events. The payload is a JSON object with event names (like “tool_used” with a slug like “pdf-to-jpg”), a timestamp, and anonymous session information. No IP address is stored. No cookies are set. The payload does not include file contents, prompt text, or output. You can see exactly what is sent by watching the Network tab and clicking on any request to “eu.i.posthog.com” — the full request body is visible.
Clerk authentication: Loads only on pages where signing in is relevant. If you are not signed in and not on a page requiring authentication, Clerk does not load. Clerk handles account state: who you are, whether you are a Pro subscriber, session tokens. It does not receive file contents or prompt text.
Google AdSense: Loads on tool pages for non-Pro users and serves display ads. Google receives the page URL and standard browser information used for ad targeting. It does not receive file contents or prompt text, because those never reach any server.
You can verify the PostHog claim directly: open the Network tab, use a tool, and inspect the PostHog event payload. It is plain JSON and the contents are readable without any special knowledge.
Claim: “The site works without internet after the first visit”
This applies to the file tools. The AI tools require a model download on the first visit but then also work offline.
How to check it: Visit any file tool. Use it once with a normal connection. Turn on airplane mode. Hard refresh the page. Drop a file. The conversion should complete normally and the download should appear.
If it does not work offline, that is a regression and a bug. The offline-after-first-visit behavior is architectural: the conversion code runs in the browser, the page is cached by the browser, and after one visit the tool has everything it needs locally. No server is involved in the conversion.
Where a sneaky upload could hide, and why it cannot
Once you start watching network traffic, the natural next question is whether someone clever could hide an upload somewhere the Network tab does not show. The honest answer is no, and it is worth saying why, because the claim only matters if the verification is actually thorough.
Hidden iframes do not work as a hiding place. Pages embedded inside a parent page still have their requests recorded under the parent in the Network tab; the developer tools do not let an embedded document hide its outbound traffic from the surrounding page. WebSocket connections are not a hiding place either. They appear under their own filter in the Network tab, and the messages that travel across them are inspectable. Image beacons — tiny image requests with file data smuggled in the URL — show up as image requests in the Network tab, and you can read the URL. Background workers and helpers spawned by the page show up too, with their own request lists.
The browser is, as a design choice, thorough about showing the developer tools every request the page initiates. There is no “invisible” mode for a page to make requests the developer tools cannot see. This is not an accident; it is a property of the platform. It is also one of the reasons the web is a reasonable place to make a claim like “your file does not leave the tab” in the first place.
What this audit does not cover
We want to be honest about the limits. The audit covers what this site does. It does not, and cannot, cover everything that happens on your computer.
Your operating system may collect telemetry of its own. Your browser may collect telemetry of its own — some browsers send certain types of usage data to their vendor by default, others let you opt out, and the details vary. Your internet service provider can see that you visited this domain, the same way they can see every domain you visit. None of those are things the site can speak to, because they are outside of what the site does.
What the site can speak to is what it does, and that is what the Network panel shows. The site does not upload your files. It does not phone home with your prompts. It loads the third-party services we listed, and only those, and only on the pages they belong on. Those claims are checkable in five minutes. The wider story of device-level privacy is a longer conversation, but it is not the conversation this site is responsible for.
What to do if something does not check out
If you run any of these checks and find that the results do not match the claims, that is worth flagging. A request appearing in the Network tab when the claim says no request should appear is either a privacy regression or a false claim, and neither is acceptable. The honest response to a verified discrepancy is to fix the code, not rewrite the claim.
Send what you found to the contact addresses on the privacy page. Include the steps you took, the request you saw, and what you expected instead. We will reproduce it, fix the underlying cause, and write up what happened. We would rather hear about a discrepancy from a careful reader than have it slip through.
The full privacy policy lists every third-party service, what data is transmitted, and the reasoning behind each one. The policy is meant to be cross-referenced with the Network tab, not to stand alone as an assertion you are expected to trust. The story of why the site is built this way is on about; the contact details for reporting an issue are at the bottom of either page.
The broader principle behind all of these claims is simple. A privacy claim that can be falsified by two minutes with a Network panel is either verifiably true or immediately wrong. We chose to build the site so that all of its core claims fall into the first category. The Network tab is the witness. You do not have to take our word for any of it.