How Zero Send Works

What Zero Send means

Zero Send is the processing principle of ZEKILO Dev: the site does not send what you type or paste into a tool out of this browser. Input here means the text you enter, the contents and name of a file you open, and the result. The site does not send input to a server, to analytics, or into the page address (URL), and it does not store it.

This page explains how that principle is implemented and how you can check it yourself. The last section lists what Zero Send does not cover.

Where processing happens

• Every tool runs as JavaScript in your browser, on your device. The site has no server program that receives and processes input.
• ZEKILO Dev consists only of static files (HTML, CSS, JavaScript, fonts, icons) hosted on Cloudflare Pages. There is no application server, no database, no user accounts, and no sharing links that store input.
• Small inputs are processed directly in the page. Inputs larger than 64 KB and tasks that take time are processed in a Web Worker. A Web Worker is a separate execution space inside the same browser that runs apart from the screen. It is not another computer.
• Tasks that can run for a long time, such as regular expressions, run in a dedicated Worker with a time limit of 1 second.
• Opening a file also reads the file inside the browser. The site does not send the file anywhere.

Network requests

The site makes the following three kinds of network requests.

Request	When	Your input
Static files of this site (pages, scripts, fonts)	When a page opens, and when a tool is used for the first time	Not included
Analytics (Google Analytics 4)	On the production site (dev.zekilo.com), when a page opens and when a tool is used or hits an error	Not included. Tool events carry only the tool ID, kind of action, input size range, and error code
Advertising (Google AdSense)	After ads have started, when a page that has the advertising script opens	Not included

• The site sends only two analytics events, tool_use and tool_error. The input size is sent only as one of four ranges (<1K, 1-64K, 64K-1M, >1M), never as an exact length. The code filters out any value that is not on the allowlist.
• The analytics script is loaded only when a page is opened on the production domain, and only after a measurement ID has been configured. The analytics and advertising scripts are provided by Google, and once loaded they send their own requests to Google’s addresses. What they transmit is listed in the Privacy Policy.
• The about page and the policy and information pages, including this one, carry no advertising script.
• “Copy” puts the result on the clipboard, and “Paste” reads the clipboard into the input box only when you press the button. “Download” creates the file inside the browser and saves it. None of these is a network request.
• The error report link opens your mail app. It fills in only the tool ID, the page address, your browser and operating system, and the error code. Your input is not included.

What is stored

Input and results are not stored. They are gone when you reload the page or close the tab. The only values kept in browser storage are the following.

• zd-opt: plus the tool ID (localStorage): tool option values such as indentation. Example: zd-opt:json-formatter
• zd-lang (localStorage): the display language chosen in the language menu
• zd-consent (localStorage): the date you acknowledged the cookie notice banner
• zd-ref (sessionStorage): the address of the referring page when you arrive at the root page (/) from another site and are moved automatically to the Korean or Japanese pages. It is passed to analytics once and then deleted, and it is also deleted when you close the tab.

The site itself sets no cookies. You can open Local Storage and Session Storage in the Application tab of the developer tools to confirm that only the values above are there.

Libraries

• Some tools, such as YAML, CSV, SQL, text diff, and hashing, use open source libraries. The libraries are built together with the site and served from this site’s own address (under /_astro/). They are not fetched from an external CDN.
• A tool’s processing code and its libraries are downloaded from this site the first time you enter something into that tool. Those requests fetch files and do not contain your input.
• Fonts are also served from this site.
• Libraries are pinned to exact versions, and the list and licenses are published on the Open Source Licenses page.

Content Security Policy (CSP)

• The site sends a Content Security Policy in its response headers. The connect-src directive of the policy defines where scripts may exchange data, and it lists only this site itself ('self') and Google’s analytics and advertising addresses.
• The script-src directive does not contain 'unsafe-eval'. The site does not run strings as code (eval).
• The policy is currently sent as a report-only header (Content-Security-Policy-Report-Only). In report-only mode the browser does not block a request that violates the policy. It shows the violation in the developer tools console instead. We plan to switch to the blocking mode after confirming that it does not conflict with analytics and advertising, and we will revise this page when we do.
• CSP is a supporting safeguard. That the site does not send your input is confirmed by the automated check and the manual check below.

Automated check

• Automated tests type a marker string (ZD-SECRET-7f3a) into the tools in real browsers, then process, copy, and download, and inspect every request the browser sent.
• A test fails if the marker appears in a request address, a request body, a request header, or data sent over a WebSocket. URL-encoded, Base64, and hexadecimal forms of the marker are searched as well.
• The tests also check whether the marker remains in localStorage, sessionStorage, the page address, or cookies, and whether any localStorage value was created under a name other than the allowed ones (zd-opt:…, zd-lang, zd-consent).
• The check runs in three browser engines (Chromium, Firefox, and WebKit) and is run again whenever the code changes.
• The check runs against a test build with analytics and advertising switched on. The Google analytics and advertising scripts themselves are not executed in the test: requests to Google are intercepted and answered with an empty response.
• A separate test, which imitates the production domain, confirms that the values this site’s code hands to analytics (tool ID, kind of action, input size range, error code) contain none of your input.

How to verify it yourself

Anyone can check with the browser’s developer tools. Use a recognizable test string such as my-test-12345 instead of a real secret.

1. Open a tool page and open the developer tools (F12 or Ctrl+Shift+I, or Cmd+Option+I on macOS).
2. Open the Network tab and clear the log.
3. Paste the test string into the tool and watch the result appear.
4. Look at the new requests. The first time you use a tool, there may be requests for script files whose path starts with /_astro/. They are GET requests that fetch files, and the test string is not in their addresses.
5. On the production site there may be requests to google-analytics.com. Select one and look at its address and Payload: it holds the event name, the tool ID, the kind of action, the input size range, and the visit information that Google Analytics adds (such as the page address and identifiers), and not the test string.
6. If the list has any request whose method is POST, open its Payload and confirm that the test string is not there.
7. After you have entered something once and seen a result, turn on Offline in the Network tab or disconnect from the network, then change the input. If the result keeps changing without a connection, processing is happening inside the browser.

Limits of Zero Send

Zero Send means that this site’s code does not send or store your input. The site cannot prevent the following.

• Browser extensions: an extension with permission to read page content can read your input too. If that concerns you, use a window with extensions turned off, such as a private window.
• The state of the device: a device infected with malware, programs that record keystrokes or the screen, and monitoring or security software installed by an organization can see what is inside the browser.
• Screen sharing and recording: during screen sharing, remote support, or screen recording, the input visible on the screen is passed along as it is.
• The clipboard: a copied result goes to the operating system’s clipboard. If clipboard history or cross-device sync is turned on, it may remain there.
• Downloaded files: a downloaded result file stays on your device, and looking after it from then on is up to you.
• Third-party scripts: on the production site, Google’s analytics and advertising scripts run in the same page. The site does not pass your input to these scripts, but their code is managed by Google. The tools keep working if you block these scripts with an ad or tracker blocker.
• Visit records: the requests that open the site (IP address, page address, browser information) reach the hosting provider and analytics. They are unrelated to your input, but this does not mean that no information at all is transmitted.
• Future changes: this description is accurate as of the last updated date shown above. The site’s code can change, so check for yourself with the steps above before you handle important values.

For values that would cause serious harm if leaked, such as production keys and passwords, it is wise to check your organization’s security rules first, whichever online tool you use.

Contact

If what this page describes differs from what you observe, please let us know: manager@zekilo.com