Security and data handling
What FileChanger stores, for how long, who can reach it, and what happens when a conversion fails. This describes how the software behaves, so you can check it rather than take our word for it.
Last checked against the running code on 18 August 2026. It describes current behaviour rather than forming a contract. If you need this as a contractual commitment, ask and we will put it in writing.
The life of a file you convert
A conversion is deliberately short-lived. Nothing about it is designed to keep your document.
- You upload a file.It is stored under a random identifier that nobody can guess, and it is readable only by this service.
- We convert it.The conversion runs inside this server. The file is not sent anywhere else.
- The input is deleted.As soon as the conversion finishes, whether it succeeded or failed.
- You download the result.The output is deleted the moment it is handed to you, so asking for the same result a second time returns nothing.
- Anything left over expires.If you never collect the result, both files are deleted when the job expires.
A sweeper runs every 60 seconds and deletes the files of any job that reached its expiry without being collected, so an abandoned conversion is removed within about a minute of expiring. Jobs expire 1 hour after they are created.
What we keep, and for how long
| Data | Kept for |
|---|---|
| The file you uploaded | Until the conversion finishes, then deleted. 1 hour at the very most. |
| The converted result | Until you download it, then deleted. 1 hour at the very most. |
| The job record (formats, sizes, status) | 1 hour, then marked expired |
| A record that a conversion happened | Permanently. Formats, byte sizes, duration, success or failure, and the error text if it failed. |
| Your account and usage counters | Until you ask us to delete the account. There is no self-serve delete button yet, so email us and a person does it. |
| API keys | Until you revoke them. Stored as a SHA-256 hash, never as the key. |
The permanent row is the one worth reading twice. We keep a record that a conversion happened, because it is how billing and error rates work. That record describes the conversion. It does not contain the document.
What we never store
These are absent from the database schema, not merely deleted after the fact.
- The name of your file. There is no filename column anywhere in the database.
- The contents of your file, or any part of it, once the conversion is done.
- Your email address or your name. Your account is identified by a token from the sign-in provider.
- Your API key. Only a SHA-256 hash of it and the first few characters, so you can tell your keys apart.
- Card details. Payment is handled entirely by the payment provider and never touches this service.
Who can reach your files
Only your account
A conversion belongs to the account that created it. A request for someone else's job returns "not found", so it does not even confirm that the job exists.
Unguessable identifiers
Files are stored under a random version 4 UUID. There is no sequence to walk and no listing to read.
No public link to a file
The service never generates a shareable or time-limited storage URL. It reads your file with its own credentials and hands you the bytes over HTTPS, so there is no link to leak.
A short window
The strongest access control here is time. A file that has been deleted cannot be exposed by a later mistake.
How the conversion runs
Your file is converted by this server, in this process. It is not passed to another conversion service, and no separate program is started to handle it.
The conversion engines are compiled into the server itself. That matters for two reasons a security reviewer will care about: your document is never written to a command line or handed to a shell, and there is no third party in the conversion path who would also need to be assessed.
Traffic runs over HTTPS. The service runs on two independent servers from two different providers, both serving live traffic, so one can fail without taking the service down.
The services we rely on
FileChanger uses outside providers for the pieces below. Each one receives only what its job requires.
| Role | What it receives |
|---|---|
| Object storage | The uploaded file and the converted result, for the short window described above. |
| Managed database | Your account, usage counters, API key hashes, and conversion records. No file contents. |
| Sign-in provider | Your email address and login. This service holds only the resulting user id. |
| Payment provider | Your billing details and payment method, plus the byte totals we bill on. It never sees a file. |
| Product analytics | Page views and conversion events, including the formats converted and whether it worked. Never file names or contents. |
If you need the providers named for a data protection assessment, email us and we will confirm them in writing.
Where your data is processed
| Component | Location |
|---|---|
| Application server (one of two) | Virginia, United States |
| Application server (two of two) | Quebec, Canada |
| Database | Virginia, United States |
| Object storage, holding files mid-conversion | Not pinned to a region. It uses the provider's default jurisdiction rather than its EU-only option, so an object can be stored outside Europe. |
| Conversion itself | In the application server process, so the same country as whichever server took your request. |
Both servers take live traffic, so a conversion runs on whichever one answers you. You cannot pin a conversion to a country.
The honest summary: FileChanger runs entirely in North America. There is no European or United Kingdom region today. If you are in the UK or the EEA, sending us a file containing personal data is a restricted transfer, and your assessment should treat it as one. We would rather you learn that here than three emails into a procurement process.
Converting without an account
You can convert a file without signing in, up to 10 MiB per file and 5 conversions a minute. The same deletion behaviour applies.
To apply that rate limit we have to tell one visitor from another, so we store a SHA-256 hash of the connecting address rather than the address itself. We would rather be precise than flattering here: a hash of an IPv4 address can be reversed by trying every address, so treat this as a stored identifier, not as anonymisation. Signing in avoids it entirely, because a signed-in conversion is attributed to the account instead.
When something fails
A failed conversion deletes its input immediately, in the same code path as a successful one. Failure is not a way for a file to survive longer.
We keep the error text so we can fix what broke. Error text comes from the conversion engine and describes the problem, for example an unsupported format or a malformed file. If a document is malformed, an engine's message can quote the fragment it choked on, so assume the error record can contain a small excerpt of the input.
Errors shown to you are deliberately generic. An internal failure is never rendered into the page, so a stack trace or a database message cannot leak through the browser. The detail stays in our logs. A failed sign-in also gives you a reference id you can quote to us, which lets us find the exact event without you describing it.
What we do not have
Stated plainly, because you would find out during procurement anyway.
- No SOC 2 or ISO 27001 certification.
- No independent penetration test.
- No published uptime history or status page.
- No European or United Kingdom hosting region, and no way to keep a conversion inside one country.
- No customer-managed encryption keys.
- No signed data processing agreement as a standard document, though we will sign one.
If one of these blocks a purchase, tell us which. It is more useful than a guess about what buyers want.
Ask us anything here
A real person answers, and questions about this page are welcome, including awkward ones.