PR—Privacy
Which tools run locally, and which need a network
DevKit Tools has 122 tools, and 118 of them do all their work on your own device. The remaining 4 are network diagnostics that cannot work without a connection. This page draws that line clearly instead of vaguely claiming that "everything runs locally".
118 tools have no upload path at all
They are built entirely on native browser capabilities: native parsers for JSON and URLs, Web Crypto for hashing and encryption, DOMParser for XML, Canvas for images, and crypto.getRandomValues for randomness. There is no code path that sends your input to a server.
Your input is never persisted
What you type lives only in the memory of the current page. Refresh or close the tab and it is gone. Nothing is written to localStorage, cookies or any server. The site itself stores exactly two keys in localStorage: your light/dark theme choice and your language choice.
Analytics and ads cannot reach your input
The site uses Google Analytics 4 to learn which tools people actually use, and Google AdSense to cover running costs. They see ordinary visit information — which page you opened, where you came from, your device and rough region — and they set their own cookies. What they cannot see is what you type into a tool, because that never leaves page memory and is never written anywhere a third party can read. Our hard rule: no analytics event ever carries tool input or any fragment of it, only non-reversible values such as a size bucket.
You can verify this yourself
Open the Network panel in your browser’s developer tools, enable "preserve log", then paste and process something on any tool page. You will see the page’s own static assets, the editor assets, and script requests to googletagmanager and googlesyndication — but not a single request carrying your input. You can expand each analytics request and check its parameters against the table below.
These 4 tools go through our server
A DNS lookup has to query a resolver, reading a certificate requires a TLS handshake, cross-origin response headers cannot be read from a page because of the same-origin policy, and only a server can see your public IP. A browser cannot do any of these, so these tools run through this site’s server proxy — and each of them says so at the top of the page:
What the proxy does and does not do
- · It forwards only the target you enter (a domain or IP), never anything you typed into another tool.
- · It does not write your queries to a database or logging system.
- · It blocks requests aimed at private ranges, loopback addresses and cloud metadata endpoints, so the server cannot be used as a jump host (SSRF protection).
- · It rate-limits by source IP so the site cannot be used as a free scanner.
- · It sends an identifiable User-Agent rather than pretending to be ordinary browser traffic.
Exactly what we collect
Beyond Google Analytics’ standard pageview data, the site reports the custom events below. This list is the whole of it — event parameters go through a whitelist in code, so nothing outside these fields can be sent.
| Event | When it fires | What it carries |
|---|---|---|
| tool_view | A tool page is opened | Tool ID, category |
| tool_run | The first valid result is produced | Tool ID, input size bucket (empty / small / medium / large) |
| tool_copy | The copy button is clicked | Tool ID, result size bucket |
| search_open | The search palette is opened | Nothing |
| search_pick | A tool is chosen from search results | Search term, chosen tool, result position |
| category_filter | A category filter is applied | Category ID |
| fullscreen_enter | Fullscreen comparison is entered | Tool ID |
| theme_toggle | Light/dark mode is switched | Target theme |
One exception deserves calling out: search terms typed into the site search are recorded. That term is navigational intent (for example "timestamp"), and we use it to find out which tools are still missing. It is not tool content and is never linked to anything you type into a tool. If you would rather not be counted, a blocking extension or a "do not track" setting works fine — every tool on the site keeps working with analytics blocked.
One piece of general advice
Even when an online tool says it runs locally, it is not a good idea to paste long-lived, high-privilege credentials into any third-party site. A safer habit: use short-lived tokens while debugging, or run the equivalent command-line and code snippets from the tool page in your own environment.