https://txtfetch.com/security/
What's actually enforced, and what's next.
txtfetch is pre-launch and hardening in public. Here's the honest split between what's shipped today and what's on the roadmap. No claim outruns the code.
in-place-today
In-memory processing, no content store
Every request is held in memory for the duration of the extraction and never written to a datastore. See the data handling note below for the exact posture.
TLS in transit
CloudFront and the Lambda function URL terminate TLS with AWS-managed certificates (ACM). Every hop between you and txtfetch is encrypted.
AWS-managed encryption at rest
Anything txtfetch stores in AWS (S3 assets, CloudWatch logs) is encrypted at rest using AWS-managed keys (S3 SSE).
SSRF-guarded URL fetch
Server-side fetching (?url=) is restricted to http/https on standard ports, and it refuses private, internal, and link-local addresses. See the current limits on /docs/limits.
Abuse circuit breaker
A key that racks up abusive outcomes, like repeated malformed input or oversized-payload rejections, trips a lockout on top of ordinary rate limiting. See abuse_detected on /docs/errors.
Google Analytics
Google Analytics is the site's analytics provider. It sets cookies and is governed by Google's own policy. See /subprocessors.
Least-privilege intent
The extraction Lambda's IAM role is scoped to what the function needs to run. That means compute and the artifacts it reads, nothing broader.
Single region
All compute and storage run in a single AWS region (us-west-2). There's no unnecessary data replication across geographies.
on-the-roadmap
planned
Automated dependency & runtime scanning
A published patch SLA, plus CI-driven dependency and base-image scanning. See the target windows in the data handling note below.
planned
SOC 2 Type II
A formal audit is on the roadmap, not completed. Details on scope and timeline live on the /compliance page.
Read more →data-handling
No content store, and we're closing the last gap.
Document bytes are processed in memory and discarded. We do not persist document content to any datastore. We are actively closing out a request-logging path that could otherwise capture raw request data in operational logs. Until that work lands, treat this as our target posture, not a fully audited guarantee. Full detail is on the privacy page. For what extraction pulls out of a document body, and where that text goes next, see personal data in extracted text. For hidden text and prompt injection, see untrusted documents. Because there is no content store, there is also nothing to export if you leave — see leaving txtfetch.
Patch targets: critical vulnerabilities within 7 days, high-severity within 30 days. Today that's a manual process; automated scanning is on the roadmap above.
vulnerability-disclosure
Found a problem? Tell us.
Scope: txtfetch.com, the extraction API, and any subdomain of txtfetch.com. Third-party services we depend on (AWS, Google Analytics) are out of scope. Report those directly to the provider.
Safe harbor: make a good-faith effort to find and report a vulnerability. Avoid data destruction, privacy violations, and service disruption. Do that, and we will not pursue legal action against you for that research.
How to report: send details through /contact. There's no email address to guess at. Include what you found, how to reproduce it, and its potential impact.
Response window: expect an acknowledgment within 3 business days. We'll follow up with a timeline once we've triaged the report.
Get a key and send your first file.
Create an account and get an API key in minutes. The free Hobby plan needs no card.
Get started →