01
No upload step
Core workflows process files directly on the user's device. The file does not need to leave the browser to be resized, converted, merged, validated, or transformed.
Local-first browser tools
Run tools locally.
An open-source toolbox for everyday file and media processing — built for a web where users keep control of their data.
Open a tool, drop a file, process it in the browser, and download the result. No upload step. No account. No remote processing service required.
Core thesis
The web should share capabilities, not require users to surrender their files to use them.
Principles
A different default for utility tools.
Many everyday file tasks are simple enough to run in the browser, yet they still rely on opaque upload-and-process services. runlocal.tools changes that default.
02
Browser-native execution
Tools use browser APIs, Canvas, Web Workers, Streams, and eventually WASM as a portable runtime for local file processing.
03
Share tools, not files
A tool can be shared as a URL. The recipient runs it with their own local files, avoiding unnecessary file transfer between services.
Privacy first
Users stay in control.
The privacy model is intentionally simple: if a task can happen locally, it should happen locally. The platform avoids unnecessary accounts, file uploads, invisible server-side retention, and processing that users cannot inspect.
- Private files remain on the user's device.
- Processing logic is visible and open source.
- Tools remain useful without centralized accounts.
- Deployment can be self-hosted or mirrored by others.
Open web
Tools as public building blocks.
runlocal.tools is not meant to be a closed utility website. It is a set of browser-native building blocks that can be reused, extended, audited, and composed by communities, developers, and public-interest projects.
The goal is practical digital infrastructure: useful tools that do not depend on opaque services or unnecessary data extraction.
Composable workflows
Unix pipes, adapted to the browser.
The first step is dependable single-purpose tools. The larger vision is composability: outputs from one local tool become inputs for another, creating browser-native workflows without handing private files to remote infrastructure.
01
Local input
A file is selected through the browser from the user's device.
02
Focused tool
A small operation runs in the client runtime.
03
Local output
The result remains local and can be reused directly.
04
Next tool
The output becomes input for another tool route.
05
Export
The final result is downloaded, shared, or passed onward locally.
# browser-native pipeline examples
/images/resize → /images/compress → /images/convert
/csv/validate → /csv/to-json → /json/format
/images/resize → /images/compress → /images/convert
/csv/validate → /csv/to-json → /json/format
Tool index
A growing local-first toolbox.
The project starts with a small number of dependable tools and grows through shared processing primitives. The goal is quality, clarity, and reusability — not a noisy marketplace.
Images
Focused tools for common browser-side image workflows.
- Merge ImagesLive
- Resize Planned
- Convert Planned
- Compress Planned
- Crop Planned
Data
Small utilities for structured text and common formats.
- CSV ↔ JSON Planned
- Formatting Planned
- Validation Planned
- Inspection Planned
Media
Browser-native media processing where local execution is practical.
- Video trim Planned
- Video convert Planned
- Video compress Planned
- Frame extraction Planned
/images/merge
/images/resize
/images/convert
/csv/to-json
/json/to-csv
Digital commons
Built to be inspected, reused, and self-hosted.
A local-first toolbox is most useful when it is not locked behind a single service. The code and processing model should be understandable, portable, and reusable.
Open by default
Clear routes, clear behavior, and no hidden remote processing behind the scenes.
Reusable primitives
Shared browser-side processing components reduce duplication and make tools easier to extend.
Self-hostable
Organizations and communities can run their own instance when they need control over deployment.
Low-friction access
Practical utilities should work without ads, accounts, opaque infrastructure, or unnecessary uploads.
Roadmap
Start useful. Grow carefully.
The near-term goal is reliable tools for images and data. The long-term goal is a shared local processing layer for composable browser workflows.
Now
Dependable core tools
Improve Image Merge and expand into resize, convert, compress, crop, and CSV workflows.
Next
Shared processing layer
Define reusable browser-side primitives for files, previews, transformations, streaming, and exports.
Direction
Composable local pipelines
Enable outputs from one local tool to become inputs for another, inspired by Unix pipelines and adapted to the web.
Optional verification
Proof when workflows need accountability.
The main project is local-first tooling. For automated or compliance-sensitive contexts, runlocal.tools can also explore optional execution receipts: small metadata records that reference the tool, version, and hashes without exposing private files.
Example receipt metadata
Private files are not stored. Receipts can reference hashes and tool metadata.
Tool
image-merge
Version
1.0.0
Proof
verifiable_execution_receipt
Hash
sha256:...
FAQ
Plain answers.
Does runlocal.tools upload files?
No. The core model is local execution in the browser. Files are processed on the user's device rather than handed to a remote processing service.
What does “share tools, not files” mean?
A user shares a URL to a tool, not the data itself. The recipient opens the same tool and processes their own local files in their own browser.
How are pipelines different from normal web apps?
Each tool is a small focused unit. Future workflows can connect these units so an output from one local tool becomes the input for another, similar to Unix pipes.
Are receipts the main product?
No. The main project is an open local-first toolbox. Receipts are an optional layer for automated workflows, auditability, or compliance-sensitive environments.