Skip to content
FlipMyFile

Security and file handling

Last reviewed 3 August 2026

Files are processed on our own server in Singapore (AWS ap-southeast-1), stored under random names outside any public directory, and deleted on a timer: uploads within 2 hours, results within 24 hours. They are never inspected by a person, never shared with a third party, and never used to train anything.

What happens to a file, step by step

  1. UploadThe file is streamed to disk as it arrives rather than being loaded into memory first, and is written under a randomly generated name with no relationship to the name you sent.
  2. ValidationThe first bytes are inspected to identify the real format. A file renamed from .txt to .png is rejected, and so is anything above the size, resolution or duration ceiling published on each tool page.
  3. QueueA job record is created holding the tool used, the formats, the sizes, the outcome and a keyed hash of your IP address. The file itself never enters the database.
  4. ProcessingA worker in a separate container with its own memory and CPU limits opens the file, runs one operation on it and writes the result. The worker is not reachable from the internet — no port of it is published — and it runs with a timeout so a malformed file cannot occupy it indefinitely.
  5. DownloadThe result is reachable only through a link containing a random identifier. Nothing is served from a public directory, and the download path is excluded from search engine crawling.
  6. DeletionA sweep runs every 15 minutes. Uploads are removed within 2 hours, results within 24 hours, and orphaned files left behind by an interrupted job are cleaned up separately.

Encryption in transit

Every request is served over HTTPS, so the file is encrypted between your device and our server. Files at rest sit on the server's own disk for the short window described above; they are not copied to object storage or to any other provider.

Who can reach your files

Nobody browses uploads. The administration dashboard shows counts, formats, sizes, durations and error codes — the same job metadata described in the privacy policy — and has no file browser, no preview and no download of user content. It is behind a password and blocked by default at the middleware layer rather than page by page, so a new admin page cannot accidentally ship unprotected.

Downloads are addressed by a random identifier rather than a guessable number, and /api/ is excluded in robots.txt so a link cannot end up in a search index.

How uploads are validated

  • The format is detected from the file's own bytes, not from its extension or the type the browser claims.
  • Every tool has a size ceiling, and image tools also have a pixel ceiling. A small file that decodes into an enormous image — a decompression bomb — is refused before the decoder touches it.
  • Video and audio tools additionally enforce a duration ceiling.
  • Processing runs with a timeout and inside a container with fixed memory and CPU limits, so a malformed file cannot exhaust the machine.

Rate limiting, and what it is based on

Limits are applied per visitor using a keyed hash of the IP address — we do not store the address itself and cannot reverse the hash back into one. The client address is taken from the last entry in the forwarding chain, the one added by our own proxy, so sending a forged header does not change which bucket you land in.

Slots are reserved in Redis before the job is written rather than counted afterwards, which closes the race that would otherwise let a burst of simultaneous uploads slip past the ceiling.

Metadata is removed by default

EXIF data can carry GPS coordinates, camera serial numbers and timestamps. Image tools strip it unless you explicitly ask to keep it, so a photo taken at home does not carry your address into whatever you post it to.

What the system does not have

  • No user accounts, so there are no passwords or password resets to attack.
  • No payment processing, so no card data exists anywhere in the system.
  • No third-party service that receives your files.
  • No advertising scripts and no cross-site trackers.
  • No training of machine-learning models on anything you upload.

Reporting a problem

If you find a security issue, please report it through the contact form with enough detail to reproduce it, and give us a chance to fix it before publishing. There is no bug bounty programme — pretending otherwise would be another thing on this page that is not true.