Privacy-first is not a badge added to ToolGarden after the tools were built. It is the default data path: when a browser can perform a task well, the text or file stays on the user’s device and the browser creates the result.
That matters for ordinary work. JSON can contain customer records, screenshots can reveal internal dashboards, ZIP archives can hold source code, and PDFs can contain contracts or identity documents. Uploading those files to an unknown conversion server creates a copy and a trust decision that many small tasks do not need.
The website delivers the application. Your browser performs the transformation. Tool input is not sent to a processing API.
What “privacy-first” means here
ToolGarden separates the page-delivery data flow from the tool-input data flow. The site still loads HTML, JavaScript, CSS, fonts, WebAssembly modules, workers, and sometimes model files. Page-level analytics or advertising may also make their own documented requests. Those requests are not the same as uploading the JSON, image, archive, document, or media file selected inside a tool.
For supported workflows, the selected input remains in browser memory or browser-managed local storage while JavaScript and Web APIs process it. The result is exposed as text, a preview, a Blob, or a local download. ToolGarden does not need a server-side job queue, temporary upload bucket, conversion log, or retention policy for that input because it never receives it.
The four promises shown on every tool
- ✓ Runs locally in your browser
- ✓ Your files are not uploaded
- ✓ No server-side processing
- ✓ No account required
These statements appear on every tool page as a concise summary of the processing boundary. The tool-specific article below each workspace explains the actual input API, parser or library, output method, supported formats, and limits, so the privacy claim can be checked against a concrete implementation rather than treated as a generic slogan.
How each tool category works
| Input | Local implementation | What stays on your device |
|---|---|---|
| ZIP archives | fflate reads, compresses, and extracts archive entries in browser JavaScript. | Filenames and file contents |
| Images | File, Blob, ImageBitmap, Canvas, OffscreenCanvas, Web Workers, WebCodecs where available, and local WASM codecs. | Source pixels, previews, edits, and exports |
| JSON and structured text | Browser JavaScript plus pure parsers and converters for formatting, validation, repair, diffing, JSONPath, YAML, XML, and CSV. | Pasted payloads, configuration, logs, and results |
| Base64 and text encodings | TextEncoder, TextDecoder, Blob, FileReader, browser Base64 primitives, and Web Crypto where hashing or cryptography is required. | Plaintext, encoded values, and selected files |
| PDF and documents | pdf-lib, PDF.js, Canvas, fflate, and format-specific browser libraries handle supported merge, split, render, extract, and export workflows. | Document bytes and rendered pages |
| Audio and video | Web Audio, media elements, Workers, FFmpeg WebAssembly, and local speech or separation models where supported. | Media samples and generated output |
| Local AI tools | ONNX Runtime Web, Transformers.js, WebAssembly or WebGPU, and downloaded model assets run inference on the device. | Images, audio, intermediate tensors, and results |
ZIP files: fflate instead of an upload service
ZIP compression and extraction use fflate, a compact JavaScript compression library. The browser reads each selected File, creates or parses archive entries, and returns a Blob for download. Because archive filenames and contents are handled in the tab, a source-code bundle, document folder, or photo collection does not need to pass through a remote decompression endpoint.
The tradeoff is memory. Browser tabs have finite memory, and archive operations may temporarily hold input, decompressed data, and output at the same time. Very large archives, encrypted formats, damaged ZIP files, or unusual compression methods may be better handled by trusted desktop software.
Images: Canvas, Web APIs, Workers, and local codecs
Image tools decode files with browser APIs, draw pixels to Canvas or OffscreenCanvas, apply transforms, and export a new Blob. Workers keep expensive operations away from the interface. When the browser cannot natively encode a target format, a local WebAssembly codec can provide that capability without sending the image away.
Canvas export commonly removes EXIF metadata. That can reduce accidental location leakage, but it can also remove copyright or workflow metadata. Users should inspect the output when metadata matters, and keep an untouched original until the result has been verified.
JSON: ordinary browser JavaScript, deliberately kept local
JSON formatting does not require a cloud service. ToolGarden uses JavaScript parsers and pure utility functions for formatting, minifying, repairing, validating, comparing, querying, and converting structured data. React pages manage input and presentation; parsing and conversion live in reusable utilities that return explicit success or error outcomes.
This is especially useful for API responses, configuration files, logs, and JWT payloads. Local processing removes an unnecessary network hop, but users should still redact secrets before sharing the output and remember that decoding a token is not the same as decrypting it.
Base64: encoding is local, but it is not encryption
TextEncoder and TextDecoder convert Unicode text to bytes and back. Blob, FileReader, and browser Base64 primitives handle files and data URLs. These operations are deterministic and can run entirely in the tab. No remote encoder is needed.
Base64 only changes representation. Anyone with the encoded value can normally decode it, so it must not be presented as a privacy or security control. When confidentiality is required, use appropriate encryption and key management rather than an encoding tool.
PDFs and documents: parse, render, transform, and package locally
PDF tools read selected files through the File API. PDF.js parses and renders pages; pdf-lib handles operations such as merge, split, extraction, organization, watermarking, and encryption; Canvas creates page images and previews. Office formats are ZIP-based packages, so supported document workflows can use fflate together with XML and format-specific libraries before returning a PDF, DOCX, or other Blob.
The input bytes, page content, rendered canvases, and generated document remain in the tab. Complex Office layouts, signatures, forms, annotations, accessibility structure, and archival requirements still need careful output review.
Audio and video: Web Audio and FFmpeg WebAssembly
Media tools use File and Blob URLs for local playback, Web Audio for decoding and signal operations, and FFmpeg WebAssembly for supported conversion, trimming, extraction, or compression tasks. Speech recognition and stem separation use model assets downloaded to the browser, while the selected recording or media file stays on the device during inference.
Large media files consume substantial memory and CPU. The first model or FFmpeg load can also be large, so the page makes progress and browser limits visible instead of quietly switching to a remote processing job.
Text, QR codes, and file merging: deterministic browser libraries
Text counters, diff tools, Markdown conversion, subtitle parsing, URL building, timestamps, UUIDs, color conversion, and QR generation operate on strings or typed arrays in JavaScript. File-merging tools read each input with the File API, combine rows, pages, slides, XML parts, images, or text according to the format, then create a downloadable Blob. No account or server job is required for these deterministic transformations.
Each tool page documents its own parser and output constraints. A CSV merge has different correctness risks from a DOCX package merge, even though both share the same local-only data path.
Heavy tasks: WebAssembly, Workers, and on-device models
Some jobs need more than built-in browser functions. PDF parsing, AVIF encoding, audio conversion, speech recognition, background removal, and similar features can use WebAssembly, Web Workers, WebGPU, or local machine-learning models. The browser may download a runtime or model on first use, then applies it to the user’s data locally.
A model download is network activity, but it should contain application assets rather than the user’s input. ToolGarden treats that distinction as part of the product contract and documents cases where browser support, memory, file size, or model quality limits the workflow.
How to verify a no-upload claim
- Use a harmless sample file rather than sensitive production data.
- Open the browser developer tools and select the Network panel.
- Clear existing requests, run the tool, and inspect new POST, PUT, WebSocket, or unusually large requests.
- Distinguish application assets such as scripts, WASM, workers, and model files from request bodies containing your sample.
- Repeat the check after major product changes or when using a tool with a different processing model.
Limits and honest exceptions
Browser-local processing reduces exposure; it does not make every workflow automatically secure. The correct domain, HTTPS delivery, browser extensions, device security, downloaded output, clipboard history, and local backups still matter. Highly regulated or extremely sensitive material may require an approved offline environment even when a web tool makes no upload.
- Large files can exceed browser memory or take longer than desktop software.
- Specialized or encrypted formats may be unsupported.
- Complex document layouts and color workflows can lose fidelity.
- First use may require downloading a codec, runtime, or model.
- Analytics and advertising are separate site data flows described in the privacy policy.
The policy in one sentence
If a useful transformation can run reliably in the browser, ToolGarden keeps it there, explains the technology and limits, and avoids creating a server-side copy of the user’s input.