Data Handling

This page describes how CyberTools handles the data you provide to its tools. Headline: the vast majority of tools execute client-side in your browser; for the small subset of tools that require server-side queries (DNS, WHOIS, IP lookup), the queries are processed without logging your input alongside personally-identifying information.

1. Why this matters for security tools

When you use a hash generator on a password, an encoder on an API token, or a JWT decoder on an authentication token, the input is potentially sensitive. A naive tool implementation that POSTs your input to a server creates several risks:

• Server logs may capture the input (intended or not).
• Network capture between your browser and the server exposes the input to anyone with network access.
• Server-side processing creates a centralized target for attackers.
• The server operator becomes a trust party for your sensitive inputs.

The mitigation is architectural: execute the tool in your browser, where it never reaches a server. Modern browsers provide cryptographic primitives (Web Crypto API) and JavaScript runtimes capable of executing the operations. CyberTools' default position is to use this architecture for any tool where it is feasible.

2. Tool-by-tool classification

Client-side tools (the majority)

The following categories execute entirely in your browser. Input does NOT leave your device:

Tool categoryImplementation approachCryptographic hash tools (SHA-1, SHA-256, SHA-384, SHA-512, MD5, HMAC variants) | Web Crypto API for SHA family; vetted JavaScript libraries for MD5 / HMAC where Web Crypto coverage is incomplete
BCrypt hash generator | bcrypt.js client-side library
Encoders / decoders (Base64, Base32, hex, URL, HTML entity, ROT13, Caesar, Punycode) | Browser-native APIs (atob/btoa, URLSearchParams, etc.) with vetted helpers for less-common encodings
JWT decoder (read-only inspection of header and payload) | JavaScript JSON parsing of base64-decoded segments
JSON tools (formatter, validator, JSON-to-XML, XML-to-JSON) | Browser-native JSON.parse / JSON.stringify with format helpers
Regex tester | Browser-native RegExp engine
Password generator | window.crypto.getRandomValues() for cryptographically-secure random selection
UUID generator | crypto.randomUUID() (modern browsers) or vetted fallback
Random number / string generators | window.crypto for cryptographic randomness; Math.random() only for non-cryptographic purposes
QR code generator | Client-side QR encoding library; no data leaves browser
Color picker / gradient generator | Browser canvas / CSS APIs
Image format conversion (basic) | Browser canvas for raster format conversion; no upload
Text utilities (word count, case conversion, line sorter, diff) | JavaScript string operations
Date / time tools (Unix timestamp, time-zone, ISO 8601) | JavaScript Date API
CSV / YAML parsers | Vetted client-side parsers
Lorem ipsum generator | Client-side template substitution
Numeric base converters (binary, octal, decimal, hexadecimal) | JavaScript parseInt / toString with radix

For these tools: data does not leave your browser. The tool form does not POST to the server; the operation runs in browser JavaScript; the result is displayed in the browser. CyberTools' servers do not see the input or output. The only network requests during tool use are for static assets (CSS, JS, images) and AdSense ad-loading.

Server-side tools (the minority)

The following tools require external queries that cannot execute entirely client-side:

ToolWhy server-sideData handlingDNS lookup (A, AAAA, MX, TXT, NS, CNAME, SRV) | Requires querying actual DNS resolvers; browsers do not expose direct DNS APIs | Query for hostname is sent to our backend; backend performs DNS query; response returned. No log of (user IP + hostname) maintained beyond ephemeral processing.
WHOIS lookup | Requires querying WHOIS registries; browsers cannot directly query WHOIS | Domain query sent to backend; backend queries appropriate registry; response returned. No log retained.
IP geolocation / reverse lookup | Requires geo databases or PTR queries | IP query sent to backend; backend queries geo / PTR; response returned. No log retained.
Header / HTTP probe tools | Requires the server to make HTTP request to the target URL on your behalf | Target URL sent to backend; backend makes HTTP request; response headers returned. No log retained.
Email validator (DNS / MX check) | The DNS-resolution step requires server-side | Email's domain part queried via DNS; no log of (user IP + email) retained.
Some SSL / TLS tools (certificate fetch from a URL) | Requires the server to fetch the certificate | Target URL sent to backend; certificate fetched and parsed; response returned. No log retained.

For these tools, input is processed but not logged. Specifically:

• The tool input (hostname, URL, IP, etc.) is NOT logged alongside the user's IP address in any persistent log.
• Server access logs (nginx / apache standard) may include the user's IP and the URL of the tool page they visited; this is the same as for any visit. The tool input is in form-POST data, which is not in the access log.
• Application-level logging is configured to NOT include form-POST values that contain tool input.
• Rate limiting applies to prevent abuse; rate limit data is short-lived and not used for tracking.

3. What the Site stores

The Site has minimal storage beyond the standard server-log retention covered in Privacy Policy:

• Server access logs (page URL, IP, timestamp, user agent) per the hosting provider's standard logging. Retained 30 days.
• Email correspondence with the operator at info / dmca / privacy / abuse addresses, retained per purpose of correspondence.
• Cookies and similar technologies per Cookie Policy.

The Site does NOT store:

• Tool input or output for any tool.
• User accounts, profiles, or stored credentials (no account system exists).
• "Tool history" for users (no per-user tool-use log).
• Personally-identifying associations between IP addresses and specific tool inputs.

4. Why this framework matters for AdSense and Site reputation

Search engines and AdSense reward sites that demonstrate thoughtful data-handling. The architecture documented here supports:

• EEAT signals (Trust dimension) — the Site documents and follows responsible data-handling practices.
• AdSense content-quality assessment — tools that handle sensitive input responsibly are higher-quality content than tools that don't.
• Reader trust — the developer / security audience values privacy-respectful tooling and rewards it with repeat use.

5. Limitations and honest disclaimers

• Browser security boundary applies. Client-side tools execute in your browser; the security of those operations depends on your browser's security framework. We do not extend or modify that framework.
• Network observability for server-side tools. Server-side tools transmit input over the network to our backend. The transmission is HTTPS-encrypted (TLS 1.2+); intermediaries cannot read the input. But network metadata (you visited the DNS-lookup tool's URL) is observable to network operators.
• Browser extensions can theoretically observe your tool inputs since they run in the browser context. The Site has no influence over browser extensions; this is a generic concern for any web-based tool.
• AdSense / analytics cookies may be set per Cookie Policy. These are unrelated to tool input but exist in the same browser environment.

6. How to verify these claims

The data-handling claims are observable:

• Open browser dev tools → Network tab → use a client-side tool. You should see no POST requests carrying the tool input. (Standard requests for static assets, AdSense, analytics will be visible; tool input should not be in any request body.)
• For server-side tools, you'll see POST or AJAX requests carrying the input over HTTPS. Your input is processed but not retained.

7. Reporting concerns

If you observe behavior inconsistent with this framework (e.g., a client-side tool that POSTs your input to the server when it shouldn't, a server-side tool whose response suggests retention), email privacy [at] cybertools [punto] cfd or abuse [at] cybertools [punto] cfd. We investigate.