Open tools · Local execution · No unnecessary trust
```

Simple tools. Run locally in your browser.

A universal toolbox for images, video, and data — without uploading your files to external services.

Most online utility tools are cluttered, slow, and full of ads. They ask you to upload private files for simple tasks, then turn a small job into a questionable transaction.

runlocal.tools takes a different approach. Files are processed entirely in your browser. No uploads. No server-side processing. No unnecessary trust.

🔒 Files stay on the user's device
🔗 Stable, shareable tool URLs
🧩 Composable by design
Why local

A local-first toolbox for the web.

runlocal.tools is a growing collection of practical tools for everyday file and media tasks. Each tool has a stable URL and runs where the data already is: on the user's device.

🖥️

Local execution by default

Processing happens in the browser runtime using browser APIs, Web Workers, WASM, and related client-side capabilities.

🔐

No upload step

Core workflows do not depend on sending files to a server. The tool opens, the file is dropped, and processing happens locally.

🌐

Stable, shareable routes

Tools are directly addressable through simple routes such as /images/resize or /csv/to-json.

Core idea

Open the tool, not the file transfer workflow.

Instead of sending files to remote services, users run tools locally. A person can open a stable URL, drop a file, and get a result — without handing that file to third-party infrastructure.

This changes the default relationship between utility tools and user data. It removes an unnecessary upload step, reduces dependency on centralized services, and makes the system easier to inspect and reason about.

It also makes tools easier to share. Rather than saying “upload your file to this site,” someone can simply send the tool route itself.

Why this matters

Everyday file tasks should not require blind trust.

Many simple web tools quietly assume server-side processing, even when modern browsers are capable of doing the work locally. That makes ordinary tasks slower, more opaque, and more privacy-invasive than they need to be.

  • Files often end up on systems the user cannot inspect.
  • Temporary or invisible retention is hard to verify.
  • Simple tasks become dependent on external infrastructure.
  • Ad-heavy utility sites normalize unnecessary data exposure.
Tool overview

Organized as a growing browser-native toolbox.

The initial focus is on practical, everyday tools. The long-term direction is broader: a universal set of local-first browser tools for common file and media tasks.

Image tools

Focused tools for common image workflows.

Data tools

Small utilities for structured text and formats.

  • CSV ↔ JSON
  • Formatting
  • Validation
  • Inspection

Video tools

Planned next, once the first domains are stable.

  • Trim
  • Convert
  • Compress
  • Preview
/images/resize /images/convert /csv/to-json /json/to-csv
How it works

Simple, direct, and local.

The model is intentionally straightforward: a tool route, a local file input, processing in the browser, and a downloadable result.

1

Open a tool URL

Navigate to a stable route such as /images/resize.

2

Drop a file

Provide the file locally, directly from the user's device.

3

Process in-browser

Run the operation through browser-native execution layers.

4

Download the result

Export the transformed output without a server-side handoff.

Open source

Inspectable, reusable, and self-hostable.

runlocal.tools is intended as an open project, not a closed utility service. The code, processing logic, and user-facing tools should be transparent and reusable by others.

Open by default

The platform is meant to be inspectable and understandable, with clear routes, clear behavior, and no hidden remote processing behind the scenes.

Reusable primitives

Shared browser-side processing components can support multiple tools, reducing duplication and making the system easier to extend.

Built for extension

New tools should not require reinventing the whole platform. The long-term value is in reusable local processing building blocks.

Digital commons

Practical utilities should be accessible without ads, opaque infrastructure, or unnecessary lock-in. They should be part of the commons.

Roadmap

Start small. Build shared infrastructure. Expand carefully.

The first step is a reliable set of image and data tools. From there, the project can evolve into a broader local-first toolbox with composable workflows.

Now

Core tools

Establish dependable browser-native tools for image resize, convert, compress, and CSV ↔ JSON workflows.

Next

Shared local processing layer

Define common processing patterns, file handling flows, and reusable client-side primitives across tools.

Later

Composable workflows

Enable tools to work together, allowing outputs from one task to become inputs for another in browser-native pipelines.

FAQ

Clear principles, plain answers.

Does the platform 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.

Why use stable URLs for tools?

Stable routes make tools easy to bookmark, share, and understand. They also make the platform feel like a coherent toolbox rather than a single monolithic app.

Is this just an image tool site?

No. Images are a practical starting point, but the broader goal is a local-first toolbox for everyday browser-based file and media tasks.

What makes this different from existing utility sites?

The difference is structural: local execution, no upload step, open-source implementation, stable routes, and a long-term focus on reusable and composable tooling.

Open tools. Local execution. No unnecessary trust.

runlocal.tools is a proposal for how practical web tools should work: local-first, inspectable, shareable, and built as public digital infrastructure.

Explore tools Read the principles
```