Everything happens in your browser tab
When you open a QRix tool, your browser downloads a small program — the tool's code — the same way it downloads the text and images of any web page. From that point on, the work runs on your computer or phone, inside the browser tab.
When you add a file, the browser reads it into memory on your device. It is not sent anywhere. The tool transforms that in-memory data and hands you the result as a downloadable file. The round trip from input to output happens without a network request carrying your content.
This is different from the typical online converter, where your file is uploaded to a server, processed remotely, and downloaded back. With QRix browser tools there is no upload step, so there is no server-side copy of your file to worry about.
The web platform does the work
Modern browsers include a powerful set of built-in capabilities, and QRix builds on them directly. The File API reads the files you drop in. The Canvas API draws, resizes, crops, recolors, and re-encodes images pixel by pixel — it is the engine behind most of the image and QR rendering.
For video, the browser's MediaRecorder captures frames from a canvas into a real video file, producing MP4 (H.264) where the browser supports it and WebM as a fallback. For audio and animation, dedicated encoders run in the same tab. None of these steps involve a server.
Heavy work is moved off the main thread using Web Workers so the page stays responsive, and the Web Crypto API handles any cryptographic operations locally. These are open web standards implemented by the browser itself, not custom uploads dressed up as local features.
WebAssembly for the heavy jobs
Some tasks are too demanding for ordinary browser scripting — reading text out of a scanned document, or manipulating the internal structure of a PDF. For these, QRix uses WebAssembly, a technology that lets compiled, near-native-speed programs run safely inside the browser sandbox.
Optical character recognition, which turns a picture of text into selectable text, runs as a WebAssembly module (Tesseract) entirely on your device. PDF reading and editing use in-browser PDF engines that parse and rewrite the document locally.
Because WebAssembly runs in the same sandbox as the rest of the page, these engines get speed without getting access to your machine. They see only the file you handed the tool, and only for as long as the tab is open.
Why nothing uploads
The data path is simple and worth understanding. You select a file; the browser's File API loads its bytes into the tab's memory. The tool works on those bytes using Canvas, WebAssembly, or another web API. The finished bytes are wrapped in a local Blob and offered to you as a download.
At no point in that path is there a step that transmits your file to QRix. The tool has everything it needs — the code and your file — already present in the browser. Sending the file out would add latency and risk for no benefit.
You can verify this yourself. Open your browser's developer tools, watch the Network tab, and run a tool: you will see the page and its code load, but not your file being sent. You can even disconnect from the internet after the page loads and most tools keep working.
The deliberate exceptions
A few features genuinely cannot run in a browser tab, chiefly the neural AI tasks such as generating an image from a prompt or producing a 3D model from a photo. These require large machine-learning models that live on cloud servers.
For those specific tools, and only when you run them, the input you provide is sent to an AI provider, processed, and the result returned. QRix labels these clearly and describes them in AI and video tools, so the boundary between on-device and cloud is never hidden.
Everything else — QR generation, PDF editing, image conversion, video encoding, OCR — stays on your device. When in doubt, the rule of thumb is that anything working with a file you already have runs locally, while anything that invents new content from a model uses the cloud.