How this actually works
"Your files never leave your device" is either true or it is marketing. Here is the mechanism, so you can check.
There is no server
BriskFile is a set of static files on a CDN — HTML, CSS, a little JavaScript, and a collection of image codecs compiled to WebAssembly. When you drop a photo onto the page, the browser reads it from disk into memory. That is where it stays.
There is nowhere for it to be sent. The site has no backend, no database and no upload endpoint. That is not a policy we could quietly change next quarter; it is the shape of the thing.
What happens to your file
-
The first few bytes are inspected to work out what the file really is. Extensions lie constantly — Windows
calls JPEGs
.jfif, and plenty of.heicfiles are something else entirely. - The image is handed to a background thread. Your browser stays responsive; the tab does not freeze even on a folder of several hundred photos.
- It is decoded to raw pixels — by the browser itself where it can, and by a WebAssembly codec where it cannot. Safari decodes HEIC natively; everything else uses a compiled build of libheif.
- Any resizing happens, then the pixels are re-encoded into the format you asked for.
- The result is handed back as a download. It never touched a network.
Which codecs, specifically
| Format | Encoder | Notes |
|---|---|---|
| JPEG | mozjpeg | Mozilla’s encoder; noticeably smaller files than the standard library at the same quality. |
| PNG | oxipng | Lossless re-packing. Identical pixels, smaller file. |
| WebP | libwebp | Google’s reference encoder, lossy and lossless. |
| AVIF | libavif / aom | The most efficient of the four, and by far the slowest to encode. |
| HEIC | libheif (decode only) | Used where the browser cannot decode HEIC itself. |
What we do collect
Ads. That is the honest answer, and it is why the site can be free. Our advertising partners set cookies if you allow them to, and that is entirely separate from your files — those are never part of any request, to us or to anyone else. The privacy page spells out what that means.
The trade-offs, stated plainly
- The first conversion is slower. A codec has to download and compile. After that it is cached.
- Very large images can run out of memory, especially on older phones. A server with 64GB of RAM would not; your phone might.
- Some formats we cannot read at all. Camera raw files are a different problem, and we would rather say so than half-support them.
Questions
How can I verify that nothing is uploaded?
Open your browser’s developer tools before converting, switch to the Network tab, and run a conversion. You will see the page load, and a .wasm codec download the first time. You will not see a request containing your image, because none is made.
For a stronger check, convert with your network disconnected. Everything still works.
What is WebAssembly and why does it matter here?
WebAssembly lets compiled code — in this case the same C and Rust image codecs that desktop software uses — run inside a browser at close to native speed. It is what makes local conversion practical rather than a novelty.
Why is the first conversion slower than the rest?
The codec has to download and compile the first time you use it. Afterwards it is cached by your browser, and subsequent conversions start immediately.
Does BriskFile work offline?
Yes, from your browser’s address bar, and it behaves like an app — including accepting files from your operating system’s share sheet. It still loads its pages from the network each time, so it is a faster way in rather than a copy you keep.
Is there a limit on file size?
Only your device’s memory. There is no artificial cap, no daily quota and no file counter, because there is no server cost to ration.