The documents people send you — contracts, IDs, payslips, financial records — are private and sensitive. We built uploadrequest.app from day one around protecting them. Here's exactly what we do and what it means for you and the people sending you files.
At a glance
Each section explains what we do in plain English — and for those who want to know, the technical detail too.
When your client uploads a file, it's wrapped in an unbreakable code the moment it leaves their device. Anyone trying to intercept it mid-journey would see nothing but scrambled nonsense.
How it works technically
All file transfers use HTTPS with TLS 1.3, the highest standard available. TLS is the same encryption used by banks and government websites.
When someone uploads a file, it goes directly from their browser to secure cloud storage — it doesn't pass through our systems at all. We physically cannot read it.
How it works technically
Uploads use pre-signed URLs (S3-compatible presigned PUT). The file payload goes directly from the browser to DigitalOcean Spaces (S3-compatible storage). Our application server never receives or touches the file bytes.
Even once a file is safely stored, it sits encrypted on disk. If someone broke into the storage facility — physically or digitally — they still couldn't read your files.
How it works technically
Storage-level AES-256 encryption is applied to all objects at rest. This is managed by DigitalOcean Spaces, which enforces server-side encryption on every stored file.
Every upload link is a unique, random string of characters that cannot be guessed. Even if someone tried billions of combinations, they would not find your link. The only people who can access your upload page are the people you share the link with.
How it works technically
Tokens are generated using a cryptographically secure random number generator (CSPRNG), producing a URL-safe string equivalent to a UUID v4 in entropy (~122 bits). This is computationally infeasible to brute-force.
Set a deadline on any request and the link stops working the moment that date passes. Even if someone finds the link later, they can't upload to it. No manual action required from you.
How it works technically
Expiry is enforced server-side on every request to the upload page. An expired request returns a 410 Gone status at the middleware layer before any content is served. The client-side UI change is cosmetic only — the enforcement is on the server.
Your clients upload files to your request. No one else — not other users of the app, not anyone browsing the internet — can access them. Each request is completely isolated.
How it works technically
Access to request data and file listings is gated behind authenticated sessions (via Better Auth). File download URLs are short-lived pre-signed GET URLs generated per-request, scoped to the specific object, and require the session of the owning user.
When you send a client an upload link, you're asking them to trust you with something private. Here's what we do to deserve that trust on their behalf.
The person uploading never creates an account, never enters their name or email, and never hands over any personal information beyond the file itself. They open the link, upload, and that's it.
It doesn't sit in our system. We're not an intermediary holding the file. It goes from their device to secure storage that only you can access.
The upload page clearly shows your request title and message. There's no ambiguity about who they're sending to or why.
Once you close a request or it reaches its deadline, the link is dead. If someone gets hold of the link after that point, they can't do anything with it.
We take security reports seriously. If you believe you've found a vulnerability — no matter how small — please let us know privately before disclosing it publicly. We'll investigate promptly, keep you updated, and credit you if you'd like.
Report a vulnerabilityStart for free. No credit card. Your clients' documents are in safe hands.
Get started for free