Most "About" pages tell you what a service does. This one tells you how we make decisions, where the money goes, what we test, and what data we touch. We publish this report once a year, with the next one scheduled for May 2027. If anything changes materially between reports, we update this page and note the change at the top.

1. How Z Tools Is Funded

Z Tools is currently funded entirely out of pocket by its founder. We have not taken outside investment, we do not have advertisers on the site (this site is currently pending Google AdSense review), and we do not sell user data. The total operating cost is roughly $120 per year, which covers:

  • Domain registration (~$12/year)
  • Shared hosting on HostUno (~$108/year for the plan that supports the memory limits we need for image processing)
  • Domain privacy and a few small third-party services (analytics-free, error tracking via server logs)

If we ever accept advertising, the plan is to use plain contextual ads and label them clearly. We will not run tracking-based personalized ads. We will not run affiliate links to "recommended" products unless the recommendation is genuine and disclosed. The day the funding model changes in a way that affects our privacy posture, we will publish a new report and update the Privacy Policy.

2. How We Choose Which Tools to Build

The Z Tools collection started with the six tools that the founder personally reached for in 2024 when working on side projects: a QR code generator, a password generator, a JSON formatter, an image compressor, a Base64 encoder, and a Markdown converter. They are not the most popular tools on the broader internet — they are the ones we kept needing.

When we consider adding a new tool, we apply four filters:

  1. Reuse frequency: We will not build a tool that we'd use once. It needs to be something the team returns to at least monthly.
  2. Privacy posture: We will not build a tool whose value depends on uploading user data to a third party. If a problem can be solved client-side, we solve it client-side.
  3. Existing alternatives: If a high-quality, privacy-respecting tool already exists, we link to it instead of building our own.
  4. Maintenance burden: Each tool needs to be sustainable. We won't ship a tool we can't keep working for at least three years.

The current roadmap has three candidate tools: a diff viewer for text and code, a CSV-to-JSON converter, and a color contrast checker for accessible design. None of them have firm dates. We will not announce them until we are actively building.

3. How We Test Each Tool

Every tool goes through the same testing sequence before it ships:

Functional Testing

We test the happy path and at least five edge cases. For the Image Compressor, that included: a 1-pixel JPEG, a 4000×4000 PNG, a 12-megapixel phone photo with EXIF rotation flag 6, an animated GIF, and a corrupted file truncated mid-header.

Browser Compatibility

We test the current stable versions of Chrome, Firefox, Safari, and Edge. We do not test Internet Explorer (it has been retired). We do test mobile Safari on at least one iOS version and Chrome on a recent Android. Any tool that uses a Web API not yet broadly supported includes a graceful fallback or a clear error message.

Security Review

For tools that accept uploads (image compression only, currently), we:

  • Validate the MIME type using finfo rather than trusting the browser-supplied type
  • Enforce a maximum file size (10 MB) and maximum pixel count (4000×4000) to prevent memory exhaustion
  • Store uploaded files with cryptographically random filenames, never the original name
  • Delete uploaded files automatically after 5 minutes
  • Run CSRF token checks on every POST
  • Rate-limit by client IP (10 uploads per 60 seconds)

Accessibility Audit

We use semantic HTML, label every form input, ensure keyboard navigability, and aim for WCAG 2.1 AA color contrast. We do not yet have a formal audit from a third party; that is on the roadmap.

4. What We Don't Do

Sometimes the clearest way to describe a policy is to list what we explicitly don't do. We do not:

  • Use third-party analytics. No Google Analytics, no Plausible, no Fathom. We check server logs if a tool starts misbehaving.
  • Set tracking cookies. We set one first-party session cookie for CSRF tokens, and that is it.
  • Use fingerprinting scripts, canvas fingerprinting, or any other device-identification technique.
  • Sell, share, rent, or lease any user data to anyone, ever, for any reason.
  • Embed third-party iframes on tool pages (with the exception of the Markdown tool, which uses marked.js, html2canvas, and html2pdf.js loaded from jsDelivr — these are JavaScript libraries, not tracking scripts).
  • Run A/B tests on users without their explicit consent.

5. Server, Infrastructure, and Codebase

The site runs on a single shared hosting account on HostUno. PHP 8.3 with the GD extension enabled (we use it for image processing). No database — the entire site is a handful of PHP files plus a session file and a temp directory. We chose this architecture deliberately: it minimizes the attack surface, makes backups trivial (a copy of the directory), and forces every feature to be implementable without server-side state.

The codebase is private while we are still actively building. We may open-source it in the future, particularly the image processing pipeline, which would be useful to other developers. Until then, we welcome security disclosures from researchers and credit reports (unless the reporter prefers anonymity).

6. User Feedback We Acted On

We log every email we receive, and many of them result in changes. A few examples from the past 12 months:

  • Image Compressor + EXIF rotation: Several users reported that mobile photos were sideways after compression. We fixed the EXIF orientation bug (and added this very guide to explain how it works). The fix is described in detail in the image-compress.php source code.
  • JSON Formatter + clipboard: Users asked for a one-click "copy formatted output" button. We added it.
  • Markdown Converter + PDF quality: Early PDF exports were blurry. We increased the export scale from 1× to 2×, which fixed the issue at the cost of slightly larger file sizes.
  • Navigation + Contact link: Multiple users wrote asking how to report bugs. We added a dedicated Contact page with a structured form, multiple contact methods, and a clear response-time expectation.

7. How to Verify Our Claims

Skepticism is healthy. Every claim on this page is independently verifiable:

  • View the page source — every script and stylesheet is visible. No third-party requests are made by tool pages (you can confirm this in your browser's network tab).
  • Check the cookies set during your visit — there should be one session cookie named PHPSESSID and one CSRF cookie, nothing else.
  • Read the Privacy Policy in full — it is the legally binding version of the high-level claims here.
  • Email us and ask for a copy of the access logs for your IP address. We can show you exactly which requests we logged for you, and only for you.

8. What's Next

By May 2027, we hope to have:

  • A third-party accessibility audit (we are talking to two firms about pricing)
  • One or two new tools shipped, picked from the candidate list above
  • A static analysis pass on the PHP code with PHPStan at level 6+
  • A published security.txt and a clear responsible-disclosure policy

If you want to be notified when any of these lands, the easiest way is to email us. We do not have a newsletter, and we are not building one. We will simply reply to your message when the relevant change ships.