Tasks such as compressing an image, converting a video, or inspecting a SQLite or DuckDB database may sound like work that requires a native application or a server upload. Modern browsers, however, provide enough capabilities to perform many of these tasks directly on the device.
A browser-only web tool is still running real software. It uses the browser as its execution environment and combines JavaScript, WebAssembly, and browser APIs for images and media. This article follows that flow in three stages: read, process, and return. These are not separate kinds of magic: the browser provides the entrance and exit, while the computation in the middle changes depending on the task.
Browser-local processing is “read → process → return”
Read a local file
Browser file APIs expose the contents of a file the user selected. At this stage, the file does not need to be sent to a server.
Process it with the device CPU and memory
JavaScript, browser APIs such as Canvas or WebCodecs, and Wasm-based processing engines use the device CPU and memory according to the task.
Return the result to the screen or a file
The result can be shown on screen or packaged as data such as a Blob and returned as a new downloadable file.
1. Read — Read the selected file without uploading it
The foundation is the browser’s ability to work with local files chosen by the user. A file selected with a picker or drag and drop can be exposed to a web app as file data. That may be image data, the bytes of a video file, or the database file itself.
The important distinction is that selecting and uploading are separate actions. If the web app does not perform a network upload, it can read and process the selected file locally. At the same time, the browser does not give a web page unrestricted access to arbitrary files on the computer; the user normally has to choose what to expose.
2. Process — Canvas can work directly with image pixels
Images are an area browsers have supported for a long time. Canvas can do more than display an image: a web app can read and modify pixel data, resize images, blur regions, change brightness, or combine multiple images without sending them to a server.
For formats or operations that are not convenient through built-in APIs alone, an image-processing library can also be compiled for WebAssembly and bundled into the web app. From the user’s point of view, the flow is still simple: choose an image, process it on the device, and save a new image.
2. Process — Video and audio can use codec APIs and WebAssembly
Video is heavier than image processing and involves many container and codec combinations, but browsers now expose APIs such as WebCodecs for encoding and decoding audio and video. When a codec is supported, a web app can use the browser’s media implementation for that encoding or decoding work. WebCodecs works with units such as video frames and encoded chunks; it does not by itself read or write an entire MP4 or other media container, so applications may combine it with separate container-handling logic.
Another approach is to compile an existing media engine such as FFmpeg to WebAssembly and run it inside the browser. The computation still happens on the user’s device, but codec availability, speed, and memory use can vary significantly by browser and hardware.
2. Process — WebAssembly expands the software a browser can run
WebAssembly (Wasm) makes it practical to bring existing processing engines written in languages such as C and C++ into the browser. Those programs are compiled into a binary format that browsers can execute efficiently. Instead of rewriting everything from scratch in JavaScript, web apps can reuse existing libraries and engines for image processing, media conversion, PDF work, AI inference, compression, and other jobs that once mainly lived in desktop applications.
Wasm does not give web code unrestricted access to the computer. It still runs inside the browser’s sandbox and permission model. Access to files, cameras, microphones, networks, and other resources remains governed by browser rules.
2. Process — A database engine can run inside the browser too
For databases, a web app does not have to stop at parsing file bytes in JavaScript. The database engine itself can run as WebAssembly. DuckDB-Wasm, for example, compiles the DuckDB engine to WebAssembly so a full DuckDB engine can run in the browser and execute SQL locally.
That makes it possible to give the browser a local DuckDB file or formats such as Parquet, inspect tables, run SELECT queries, and display aggregates without a database server. A page can look like it is talking to a conventional server database even though the engine is running in the tab. If the application adds remote data access or a cloud database connection, network traffic can still occur, so “database in the browser” is not automatically the same as “fully local.”
3. Return — Show the result and save it as a file
The processed result can stay inside the browser and be shown directly on screen. An image can be drawn to Canvas, SQL results can be rendered as a table, and audio or video can be exposed as preview data for playback.
When the result needs to be saved, the app can package it into browser-managed data such as a Blob and return it as a downloadable file. In other words, one continuous flow can accept a local file at the entrance, compute with the device CPU and memory in the middle, and return a new file at the exit without requiring an application server.
The trade-off is that device and browser limits become your limits
When a server is not doing the work, the CPU and memory belong to the user’s device. A few-megabyte image may be easy to process, while a multi-gigabyte video or a very large database can run out of memory or take a long time. The same web app will not perform identically on a phone and a powerful desktop computer.
Browsers also differ in codec support, APIs, and WebAssembly features, and some features such as multithreading have additional requirements. Browser-local processing is therefore not a universal replacement for server processing. Its advantages—keeping files on the device and avoiding installation—come with limits imposed by the user’s hardware and browser.
| Target | Examples available in the browser | What it can do |
|---|---|---|
| Images | Canvas / Wasm | Resize, convert, blur, composite |
| Video & audio | WebCodecs / Wasm | Encode, decode, convert, cut |
| Data & databases | DuckDB-Wasm, etc. | SQL, aggregation, file analysis |
Four things to check in a browser-local tool
Two tools can both run in a browser while using very different architectures. You do not need to understand every implementation detail; these four checks usually reveal where the work is happening.
- How files enterCheck whether the tool works only with files you explicitly choose through a picker or drag and drop. Folder access or cloud-storage integration can require additional permissions or network access.
- Where processing runsLook for explanations such as “processed in your browser,” “processed on device,” or “uses WebAssembly.” A local tool may still download its libraries or models when the page is first loaded.
- Network access“Your file is not uploaded” is different from “the page makes no network requests.” Fonts, analytics, CDNs, or cloud-saving features may still communicate for other reasons.
- Device-side limitsLarge video and database workloads are limited by the memory and processing power of the computer or phone. Check supported formats, recommended browsers, and file-size notes before relying on the tool for large jobs.
DuckDB Explorer
Open DuckDB files locally and inspect structure, data, guarded read-only SQL, and database differences.
Tips and limitations
- “Processed in the browser” is not the same as “works offline.” A local-processing app may still download libraries or models when the page first loads.
- WebAssembly still runs under the browser sandbox and permission model; it does not grant unrestricted access to the computer.
- Codec and hardware-acceleration support varies by browser, operating system, and device, so the same HTML can expose different output options or performance.
- For very large files, avoiding upload time can be useful, but device memory, heat, and battery consumption can become the limiting factors.
- Local processing can reduce file transmission, but you still need to decide whether the web tool itself is trustworthy and whether its implementation matches its explanation.
Frequently asked questions
Is a file sent to a server as soon as I select it?
Not necessarily. The browser can read a file that the user selected on the device. Uploading it requires the web app to perform a separate network operation.
Can a database really run in the browser without a server?
Yes. Projects such as DuckDB-Wasm compile the database engine itself to WebAssembly so SQL can run in the browser. Network access can still occur if the web app adds features that connect to remote data or a cloud database.
Is a browser version always slower than a native application?
Not always. Lightweight tasks may feel similar, while large datasets, heavy multithreading, GPU workloads, or specialized codecs can expose browser-specific limits.
Can the same processing run on a phone?
Often yes when the required browser APIs are available, but phones have different memory, speed, thermal, and battery limits. A large video or database that works comfortably on a desktop may be impractical on a phone.
Does browser-local processing automatically make a tool safe?
Keeping files off an external server can reduce data transmission, but it is not a complete safety guarantee. Also consider the tool’s publisher, documentation, network behavior, and storage design.
References
The browser capabilities described here are based on official specifications and documentation for user-selected files, Canvas image processing, media codecs, WebAssembly, and an example of a database engine running in the browser. Individual web tools may use different combinations, so check each tool’s documentation or published source for its actual implementation.
- W3C File API
- WHATWG HTML Standard — The canvas element
- W3C WebCodecs
- WebAssembly Community Group WebAssembly Specification
- DuckDB Foundation DuckDB Wasm Client