Pricing P2P Encrypted Chat Desktop App Browser Extension
Upload a file

AES-256-GCM · Zero-knowledge · Client-side

Zero-Knowledge Encryption

How FileShot protects your files, what we can and cannot see, and the security controls we use to prevent abuse.

Last updated: April 3, 2026 · Full whitepaper ↗

Quick navigation

What we can — and cannot — see

Zero-knowledge upload Browser encrypts before upload — we receive only ciphertext; key never leaves your browser
File contents (ZK mode) Cannot read — by design
Encryption algorithm AES-256-GCM with Argon2id key derivation
Key storage URL fragment only (#key) — never sent to server, never in logs
Password recovery Impossible by design — we do not hold the key

Validate the encryption flow yourself: Verify Encryption →

1. Goals & threat model

FileShot is designed to make sharing large files fast and simple without turning your files into a product. The main security goals are:

  • Confidentiality: prevent unauthorized access to file contents.
  • Integrity: prevent tampering with stored files and downloads.
  • Availability: keep the service usable while resisting abuse.
  • Privacy by design: minimize what we collect and retain.

We assume attackers may guess or scrape links, upload malicious content, probe the API for weak endpoints, or attempt XSS via previews or filenames. No internet service can be hack-proof — the goal is to make attacks hard, noisy, and low value.

2. Encryption modes

Zero-knowledge encryption (end-to-end)

Your browser encrypts the file before upload. We receive only encrypted bytes and do not receive the passphrase. This means:

  • We cannot read zero-knowledge file contents.
  • If you forget the passphrase, we cannot recover the file. (By design.)
  • Abuse controls rely on metadata and behavior signals instead of content inspection.

3. Cryptographic specification

FileShot uses the browser's native Web Crypto API (window.crypto.subtle) for all cryptographic operations. No third-party cryptography libraries are used.

Primitives

Cipher AES-256-GCM (NIST-approved authenticated encryption)
Key length 256 bits (32 bytes)
IV / Nonce 96 bits (12 bytes), generated per chunk via crypto.getRandomValues()
Auth tag 128 bits (16 bytes) — GCM integrity / authenticity proof
Key derivation Argon2id (memory-hard KDF)
Argon2id parameters memory: 64 MB · iterations: 2 · parallelism: 1
Salt 128 bits (16 bytes), random per upload
Key encoding Base64URL (RFC 4648 §5, no padding)

Streaming encryption protocol

Files are encrypted in a streaming fashion using a custom container format called FSZK (FileShot Zero-Knowledge):

Container magic FSZK (4 bytes)
Format version 0x01
Header Variable-length JSON (filename, MIME type, salt, chunk size)
Default chunk size 512 KB (524,288 bytes)
Per-chunk structure [AES-GCM ciphertext] + [128-bit auth tag]

Each chunk is encrypted independently with a unique IV. The per-chunk IV is derived from a base IV by incrementing the last 4 bytes as a big-endian counter. This guarantees nonce uniqueness across all chunks without additional random generation per chunk, while allowing parallel decryption.

Streaming encryption means the browser never holds the entire plaintext file in memory. For a 1 GB file, peak memory usage is approximately the chunk size (512 KB) plus overhead — not 1 GB.

4. Key management

Link-key mode (default)

A 256-bit random Data Encryption Key (DEK) is generated in the browser using crypto.subtle.generateKey(). This key encrypts the file and is then encoded as Base64URL and placed in the share link's URL fragment:

https://fileshot.io/d/<fileID>#k=<base64url-encoded-key>

Per RFC 3986, the URL fragment (everything after #) is never sent to the server in HTTP requests. This means:

  • The key does not appear in server logs, CDN logs, proxy logs, or Referer headers.
  • Each file gets a unique random key — compromise of one key does not affect others.
  • The server stores only ciphertext and has no mechanism to decrypt it.

Password mode (DEK wrapping)

When a user sets a password, the system uses a two-layer key architecture:

  1. DEK generation: A random 256-bit DEK is generated (same as link-key mode).
  2. KEK derivation: A Key Encryption Key is derived from the password via Argon2id (memory: 64 MB, iterations: 2, parallelism: 1, random 32-byte salt).
  3. DEK wrapping: The DEK is encrypted (wrapped) with the KEK using AES-256-GCM and a fresh 12-byte IV.
  4. Storage: The wrapped DEK, IV, and salt are sent to the server. The plaintext DEK and password are never transmitted.
  5. Unwrapping: The recipient enters the password, their browser re-derives the KEK from the password + salt, and unwraps the DEK locally.

The server additionally stores a bcrypt hash of the password for an access gate (to prevent unauthorized download of the ciphertext), but this hash cannot be used to derive the encryption key. The actual decryption key only exists inside the user's browser.

5. What metadata exists

Even with zero-knowledge encryption, a file sharing service needs some metadata to operate. Typical operational metadata includes:

  • File/transfer identifiers — IDs used to locate requested data
  • Filename — what you see in the UI
  • File size — for quotas and progress display
  • Expiration & download limits
  • Download counts — for UI and abuse detection

We also maintain minimal security telemetry to prevent abuse (such as IP and user-agent in security logs). See Privacy Policy for full details.

7. Previews & active content safety

File previews are a common vector for web security issues — especially with HTML, SVG, and other "active" formats. To reduce risk, FileShot treats active content conservatively:

  • Potentially active formats may be served as plain text instead of being executed.
  • Security headers reduce the blast radius of any untrusted content.

Always treat downloads as untrusted — especially executables, scripts, and macro-enabled documents.

8. Malware scanning & abuse prevention

We use layered controls to reduce malicious sharing and infrastructure abuse:

  • File-type checks and suspicious-extension enforcement
  • Rate limiting on upload, auth, and high-risk endpoints
  • Behavioral signals — download patterns, spikes, and anomaly detection

All uploads use zero-knowledge encryption, meaning the server only receives ciphertext. Content-based antivirus scanning is not possible on encrypted data. We rely on file-type enforcement, metadata analysis, and behavioral signals to detect and prevent abuse.

9. Security logging

To defend the service and investigate abuse, we log security events such as rate limit blocks, authentication events, and suspicious activity. This is operational logging — not advertising — and is governed by our privacy policy.

  • We store only what is necessary for security and debugging.
  • We do not store sensitive secrets in logs.

10. Transport & web security

Beyond client-side encryption, FileShot deploys multiple layers of transport and web security to protect users.

Transport Layer Security (TLS)

All connections to FileShot use TLS 1.2 or 1.3. TLS encrypts data in transit between your browser and our servers, providing an additional layer of protection on top of the client-side end-to-end encryption. Deprecated versions of TLS and SSL are not supported.

HTTP Strict Transport Security (HSTS)

FileShot sends the Strict-Transport-Security header with a two-year max-age, includeSubDomains, and the preload directive. This ensures browsers always connect over HTTPS, preventing protocol downgrade attacks and cookie hijacking. FileShot is eligible for the HSTS preload list, which hardcodes HTTPS enforcement into browsers.

Security headers

FileShot deploys the following security headers on all responses:

X-Content-Type-Options nosniff — prevents MIME-type sniffing attacks
X-Frame-Options DENY — prevents clickjacking via iframe embedding
Referrer-Policy strict-origin-when-cross-origin — prevents leaking URLs to third parties
Permissions-Policy Disables geolocation, microphone, camera, payment, and USB APIs — reduces attack surface
Cross-Origin-Opener-Policy same-origin-allow-popups — isolates browsing context to mitigate Spectre-class attacks
Cross-Origin-Resource-Policy same-origin — prevents cross-origin resource leaks
Content-Security-Policy Monitors script sources, blocks unauthorized resource loading, reports violations

Web Crypto API

All cryptographic operations run via the browser's built-in Web Crypto API. This provides FIPS-validated cryptographic implementations maintained by browser vendors (Google, Mozilla, Apple, Microsoft) rather than third-party JavaScript libraries. The Web Crypto API operates on non-extractable key handles when possible, preventing JavaScript code from reading raw key material.

Source code

FileShot's zero-knowledge encryption library is open source and available for independent review on GitHub.

11. Responsible disclosure

If you believe you have found a security vulnerability in FileShot, please report it privately so we can investigate and issue a fix before public disclosure.

See our dedicated Responsible Disclosure Policy ? for what to include in a report, our response timeline commitments, and researcher recognition.

Contact: security@fileshot.io

12. Data residency

FileShot's primary infrastructure and file storage operate on servers located in the United States. Encrypted file content is not cached at the CDN layer — only static web assets are eligible for edge caching.

For zero-knowledge encrypted files: the decryption key exists only in the URL fragment — never transmitted to the server and never in logs. The encrypted bytes stored on US servers carry no intrinsic value without the key, regardless of which jurisdiction requests them.

Users with strict EU data residency requirements should consult our GDPR disclosure.

Practical safety tips

  • Use a unique, strong passphrase for protected links and share it out-of-band.
  • Prefer zero-knowledge encryption for files you don't want the server to be able to read.
  • Set an expiration or download limit when sharing broadly.
  • Don't open executable files you weren't expecting — even from someone you know.
Read Security Whitepaper Verify Encryption