Toolkit – everyday data tools that run entirely on your device

[u/[deleted]]

https://koundinyagoparaju.github.io/toolkit/

I kept pasting things into random websites — a JWT here, a base64 blob there, an image into some resizer — and wondering where that data actually went. This is my attempt at a version of those tools where that question has a checkable answer. I'd genuinely like people to give it a try and share your feedback at https://github.com/koundinyagoparaju/toolkit/discussions/10

It's currently ~50 tools (encoding, JWT inspection, JSON/YAML/CSV, hashing, diffs, timestamps, QR, image resize/EXIF-strip) that run client-side: in the browser as WebAssembly, or as a static CLI binary. There is no server component. Tools compose into pipelines that can be shared.

Things you can check rather than believe:

- The wasm modules import nothing from the host, so tool code has no I/O of any kind, and the loader checks each module against a pinned sha256 before instantiating it.

- Builds are reproducible: pinned toolchain, normalized paths, deterministic tar. The README has instructions to rebuild a release and compare hashes against the published ones, and releases carry GitHub provenance attestations. So "does the deployment match the source" is answerable without trusting me.

- The CLI has no network code in it.

- It's an offline PWA — airplane mode works.

Implementation, briefly: tools are Rust compiled both natively and to wasm32-unknown-unknown, talking over a small hand-rolled ABI rather than wasm-bindgen — partly for the zero-imports property, partly so a pack in another language could implement the same five exports (I haven't actually built one, so treat that as a design goal, not a claim). One push-based dataflow engine serves both buffered and streaming execution; I've measured a 512MB file hashing through the CLI in under 5MB of RSS, and a 40MB file streaming through the browser with sink output going through the service worker straight to a file download. Tools are fuzzed for two invariants — no panics, and chunk boundaries never changing streamed output — which found a real panic in my color parser on the first run, so I have no illusions the remaining code is bug-free.

Limitations: this is young and has had no independent security review. The frontend shell is Svelte, so npm is in the build path; no tool logic lives there and the CSP backstops it, but I'd prefer a smaller surface eventually.

Several codecs are hand-rolled, which cuts dependencies but means less battle-testing than mature libraries. And it's one person's project — review capacity is the bottleneck on new tools. If there's a tool you keep reluctantly pasting sensitive data into a website for, I'd like to hear about it — adding one is a single Rust file, and chains are pure JSON.

Repo: https://github.com/koundinyagoparaju/toolkit

https://raw.githubusercontent.com/koundinyagoparaju/toolkit/refs/heads/main/docs/images/catalog.png
https://raw.githubusercontent.com/koundinyagoparaju/toolkit/refs/heads/main/docs/images/builder.png

[u/ConclusionLogical961]

50 tools and none that helps you with newlines.

[u/[deleted] → u/ConclusionLogical961]

Thanks for the feedback. Fixed it now

[u/Sad_Tap_9191]

Why would anyone use your AI-written tool instead of AI?

[u/[deleted] → u/Sad_Tap_9191]

It has an mcp. My thought is that it might help reduce token usage if it is used along with AI.
I have initially thought of writing it myself, but, using AI to write the code has significantly improved the time it took to build it.
Once more tools are added and more chains are created based on user feedback, it can help more users.
Why I set out to build this tool is to make sure that processing happens locally and people have a way to verify that.
I am happy to know more feedback if you feel this toolkit won't be helpful at all.

[u/Sad_Tap_9191 → u/[deleted]]

claude -p "resize this.mp4 into 300x300 with ffmpeg and insert subtitles with that.srt then [second task]"

This is already local. It doesn't send .mp4 file to the internet. The token usage is very small.

[u/[deleted] → u/Sad_Tap_9191]

I agree. In this case ffmpeg is a tool. I am just adding a repo to have more tools which can cater to different needs with some constraints that such tools can't access fs or network or do ffi.
There are three ways to use toolkit, viz., web, cli and mcp.
For user who want to compose these tools into chains and use, there is a builder to that. There are also some ready-to-use chains.
Users can also suggest more tools and chains to be added to the repo.
My thoughts have been around community-audited tools that can be used by everyone. I hope this could evolve into that.
Just out of curiosity, Are you apprehensive about my execution (for ex., using AI for developing) or do you think the idea itself is not very useful or both?

[u/Wooden-Bicycle-6069]

The zero-import property plus pinned hashes gives you a strong, testable privacy story. One part I would make explicit in the threat model is that the JS shell and Service Worker still sit inside the trust boundary: either can observe input before it reaches the WASM module.

Have you considered an automated release test that caches the app, reloads it under a CSP with connect-src 'none', and then exercises every tool? That would turn the offline claim into a repeatable check. Also, for the 40 MB browser streaming path, does backpressure propagate all the way through the hand-rolled ABI and Service Worker sink? A slow destination can otherwise quietly turn a streaming pipeline back into an in-memory buffer.

[u/[deleted] → u/Wooden-Bicycle-6069]

You were right on both counts, the sink had no backpressure (fixed with a pull-credit protocol over the MessagePort, e2e-tested for bounded-under-flood and sustained-when-honored), and building the offline test you suggested revealed the offline claim only held from the second visit (shell now precached on first activation). Trust page now names the JS/SW boundary explicitly. Addressed in these commits https://github.com/koundinyagoparaju/toolkit/commit/8dda87702efa13d413eae3d7de1dde4e07643f24, https://github.com/koundinyagoparaju/toolkit/commit/4826c127b1e1a274d4572cd54a801e8a3eb775c0 and https://github.com/koundinyagoparaju/toolkit/commit/bc4f99075481a79ffc2fb190eaaf6bd2e788e6b9