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 merged, cleaned of metadata, converted, or transformed.
Local-first browser tools
Run tools locally.
An open-source toolbox for everyday file and media processing — already shipping focused tools that run in your browser.
Merge image sets, strip hidden metadata, convert CSV to JSON, and verify optional execution receipts. No upload step. No account. No remote processing service required for core file work.
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 already here: dependable single-purpose tools. The larger vision is composability, where outputs from one local tool become inputs for another 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.
# live routes and near-term composition targets
/images/merge → /images/strip-metadata → local download
/data/csv-to-json → local JSON export
/images/merge → /images/strip-metadata → local download
/data/csv-to-json → local JSON export
Tool index
A growing local-first toolbox.
The project now has working tools across image and data workflows, plus a small verification layer. Planned tools stay visible here without hiding what is already usable.
Images
Focused tools for common browser-side image workflows, including batch and privacy tasks.
- Merge ImagesLive
- Strip MetadataLive
- Resize Planned
- Convert Planned
- Compress Planned
- Crop Planned
Data
Small utilities for structured text and common formats.
- CSV to JSONLive
- JSON to CSV Planned
- Formatting Planned
- Validation Planned
- Inspection Planned
Verification
Optional receipts for workflows that need a public record of tool metadata and hashes.
- Receipt verification UILive
- Tool metadata APIAPI
POST /api/receiptsAPIGET /api/receipts/:idAPI
Media
Browser-native media processing where local execution is practical.
- Video trim Planned
- Video convert Planned
- Video compress Planned
- Frame extraction Planned
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 site is past the blank-slate stage: image merge, metadata stripping, CSV conversion, and receipt verification are live. The next work is to strengthen those foundations and add adjacent tools deliberately.
Now
Polish the live tools
Harden Image Merge, Metadata Strip, CSV to JSON, and receipt verification with better shared UI, tests, accessibility, and edge-case handling.
Next
Shared processing layer
Define reusable browser-side primitives for files, previews, transformations, streaming, and exports.
Direction
Broader file coverage
Add resize, convert, compress, crop, JSON-to-CSV, formatting, validation, and media tools once the common primitives are solid.
Optional verification
Proof when workflows need accountability.
The main project is local-first tooling. For automated or compliance-sensitive contexts, runlocal.tools also has 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 a working optional layer for automated workflows, auditability, or compliance-sensitive environments.
Local-first tools for the open web.
Practical utilities for private file work: image merging, metadata stripping, CSV conversion, optional verification, and a path toward composable browser-native workflows.