Security at FileKit
A plain-language summary of how FileKit is built and where your data lives.
Processing stays on your device
PDF, image and video compression all run in your browser. File bytes are never uploaded to FileKit, so there is no server-side copy to leak.
Per-account data isolation
History and profile rows are protected by row-level security policies scoped to your user ID, enforced by the database on every read and write · not just in the UI.
Nothing to clean up
We do not keep temporary files or processed output. Files live in the tab's memory and are released when you remove them, navigate away or close the tab. Only size measurements are saved for signed-in users, and you can delete them at any time.
Secrets stay server-side
The browser only ever receives the public, publishable API key. Service-role keys and server credentials are read from the server environment and never shipped to client code, logs or responses.
Authentication
Sign-in supports email and password plus Google OAuth. New email accounts must confirm their address before the first sign-in, and password resets go through a one-time link sent to the account's email. Sessions are managed by the auth provider; signing out clears the session and the cached data in the app.
Private pages · dashboard, history and account settings · are behind an authenticated route group. Free compression tools remain usable without an account.
Data access rules
Every table storing user data has row-level security enabled with policies that compare the row's owner to the authenticated user ID. Select, insert, update and delete are all scoped that way, and the anonymous role has no access to history or profiles. Requests made outside the app with a public key are subject to the same policies, so one account cannot enumerate or fetch another account's records.
File validation
Files are checked before any processing begins: empty files are rejected, size is capped at 200 MB per file, and both the MIME type and the file extension must match a supported PDF, image or video format. Each tool additionally narrows the accepted types to the ones its engine can actually handle, and unsupported files produce a clear error instead of a crash or a silent failure.
Because parsing and encoding happen in the browser sandbox, a malformed file cannot reach a server-side decoder. Failed decodes surface as an error on the file's card.
Storage and retention
FileKit provisions no file storage buckets. There is no upload endpoint, no temporary directory and no retention window to expire · the only persisted data is the compression metadata described in the privacy policy.
Reporting an issue
If you believe you have found a vulnerability, please report it privately to the support address in the footer with steps to reproduce, and give us a reasonable window to fix it before disclosing publicly.