The reason I built ToolGarden was simple: online tools are convenient, but I did not want to upload a JSON payload, an ID photo, a JWT, or a PDF just to format, inspect, compress, or merge it.
In daily development work, sensitive details appear in ordinary places. API samples contain user IDs. Logs contain order numbers. JWTs contain tenant claims. Screenshots show internal systems. PDFs may be contracts, forms, or application material. None of these should be casually pasted into a tool whose server-side behavior is unknown.
ToolGarden treats local processing as an architectural constraint: do not send user input to the server when the browser can do the work.
Why Local Processing Matters
The risk with many online tools is not the feature itself. The risk is that you do not know what happens after upload. Is the file logged? Cached? Sent through a queue? Used for debugging? Routed through another provider? For most everyday tasks, the safest upload is the one that never happens.
Browser-local processing does not solve every security problem, but it removes a major exposure path. Files and text can stay on the device, while the website provides the interface and the code needed to process them.
The Architecture: Static Site, Browser Runtime
ToolGarden uses Next.js App Router, TypeScript, and Tailwind CSS for the interface, but the processing model is intentionally client-side. The browser downloads pages, scripts, model assets, and WASM files. The actual work happens through JavaScript, Web APIs, Workers, Canvas, Web Crypto, and local inference where possible.
Tool page
-> React state and user controls
-> lib/utils pure functions
-> Browser APIs, Web Workers, Canvas, Web Crypto, WASM, or local model inference
-> Blob, download, preview, copy
No API route receives the pasted text or uploaded file.That boundary matters. The server does not need to receive pasted JSON, uploaded images, PDF content, or token strings. It serves the app; the browser handles the input.
Thin Pages, Pure Utility Functions
To keep local processing maintainable, the tool pages stay thin. They handle state, controls, previews, and errors. Parsing, conversion, validation, compression, and export logic lives under lib/utils as pure functions or browser helpers.
type Outcome =
| { ok: true; output: string; parsed?: unknown }
| { ok: false; message: string };This keeps React components from becoming piles of one-off parsing code. It also makes failures explicit: a utility returns an ok or error branch instead of throwing raw exceptions into the page.
How Different Data Types Stay Local
| Data type | Browser-local implementation | Privacy value |
|---|---|---|
| JSON / YAML / XML / CSV | Local parsers and pure utility functions handle formatting, conversion, repair, and validation. | API samples, config snippets, and logs do not need to be uploaded. |
| JWT / Encoding | Base64URL, URL, Unicode, Gzip, hashing, and HS256 verification use browser code and Web Crypto. | Tokens can be inspected locally while debugging. |
| Images | File, Blob, ImageBitmap, Canvas, OffscreenCanvas, Workers, WASM, and local models handle compression, conversion, editing, and export. | Screenshots, ID photos, product images, and internal assets stay on the device. |
| PDF / Office / Documents | pdf-lib, pdfjs-dist, fflate, SheetJS, and browser rendering handle many read, generate, split, merge, and export flows. | Contracts, forms, and internal documents reduce upload exposure. |
| Text and subtitles | Diffing, word counting, LRC/SRT parsing, and local media previews run in the frontend. | Temporary copy, logs, and subtitle files avoid server processing. |
Local AI Where It Makes Sense
Background removal, ID photo cleanup, and watermark repair sound like features that require a cloud AI service. For ToolGarden, I prefer open-source models and local algorithms that can run in the browser. On first use, the browser may download model assets. After that, the user image is decoded, normalized, inferred, composited, and exported locally.
This is not a claim that local models always beat commercial cloud services. Edge quality, hard backgrounds, memory pressure, and batch stability all have limits. But for everyday ID photos, product shots, screenshots, and simple background edits, local inference is often good enough, and the image does not need to be uploaded.
Privacy Messaging Must Match the Implementation
SEO, sitemap entries, JSON-LD, llms.txt, Open Graph, and blog copy can easily become a separate marketing layer. I wanted the opposite: discovery metadata should describe how the site actually works. Tool descriptions come from the registry and message files, and the SEO layer adds the local-processing and no-upload positioning consistently.
That is not just wording. It is a product contract. If a tool is not registered, discoverable, documented, and honest about its processing boundary, it should not be treated as a finished ToolGarden feature.
The Tradeoffs
- Browser memory is limited, so huge PDFs, very large images, or hundreds of files can slow down or crash a tab.
- Complex Office layouts may not match desktop export engines perfectly and should be reviewed after conversion.
- Local AI models need model assets, so the first run can require a download and offline use depends on browser cache.
- Some legacy or encrypted formats are not suitable for direct browser parsing and must be clearly marked as unsupported.
- Local processing reduces upload exposure, but users still need a trusted browser, correct domain, HTTPS, and sensible handling of highly sensitive material.
The Principles I Kept
- If the browser can do the job, do not send the input to a server.
- Keep pages focused on interaction and move tool logic into utilities and Workers.
- State file-format limits clearly instead of pretending everything works.
- Make SEO and blog copy reflect the real technical boundary.
- Treat privacy as an architecture decision, not a sentence added at the end.
Summary
I did not build ToolGarden this way because browser-local processing sounds fashionable. I built it this way because it makes online tools feel calmer to use. You can paste data, drag in a file, download the result, and close the page without wondering where the input went.
The site will keep growing, but I want the direction to stay clear: push as much useful work as possible into the browser, keep the implementation understandable, state the limitations honestly, and make privacy part of the default experience.