Security
How the product is built, what an attacker could actually reach, and how to report a vulnerability.
Last updated
The short version
Your files and your text are processed inside your browser and are never transmitted to us. That removes the largest category of risk a tool like this normally carries: there is no store of customer content to breach, exfiltrate, subpoena or accidentally leave in a public bucket, because no such store exists.
What we actually hold
- No customer content. No uploaded files, no pasted text, no generated output.
- No accounts. No names, email addresses, password hashes or session tokens for the free tools.
- Server access logs — IP address, timestamp, URL, user-agent — retained for 30 days and then deleted. This is the standard request line any web server writes.
How the site is served
- HTTPS everywhere, with HTTP redirected. No mixed content.
- Static pages, pre-rendered at build time. There is no application server processing your input, so the classic injection surfaces — SQL, command, template — are not reachable, because there is nothing behind the page to inject into.
- No third-party analytics, advertising or tag-manager scripts. The fewer origins a page loads code from, the fewer parties can compromise it; ours is one.
- Dependencies are pinned and audited. A tool that runs in your browser is code we asked your browser to execute, and we treat a vulnerable transitive dependency as our problem rather than upstream’s.
What this does not protect you from
Honesty is more useful here than reassurance. Local processing means the security of your file depends on the security of your own machine: malware on your device, a hostile browser extension with page access, or someone reading your screen are all outside anything we can influence. A shared or public computer is a poor place to process something sensitive, whoever built the tool.
We also cannot promise a browser vendor will never ship a flaw in the APIs we build on. When one is disclosed that affects a tool here, we will say so on this page.
Reporting a vulnerability
Email security@tekhx.com. We aim to acknowledge within 24 hours and to keep you updated until it is resolved.
We will not take legal action against good-faith research. Test against your own browser session, do not degrade the service for other people, do not access or modify data that is not yours, and give us a reasonable window before publishing. Do that and you have our thanks and a credit here if you want one.
There is no paid bounty programme. We would rather say so than imply one exists.
Disclosure
If a vulnerability affected visitors, we will publish what happened, what the exposure was and what changed — on this page, dated, and without waiting to be asked.