ToolChop

How ToolChop works

The short version: every tool on this site runs entirely in your web browser. Your files never leave your device. There is no server-side processing, no upload step, no account, and no analytics tied to what you process. This page explains how that's actually implemented, so you don't have to take that on faith.

Why browser-only?

The technical motivation is that modern browsers are extremely capable. The Canvas 2D API can read, decode, and re-encode images in every format that matters. WebAssembly runs decoders for newer formats (HEIC, AVIF) at near-native speed. PDF.js — Mozilla's renderer, the same one Firefox uses — parses PDFs in JavaScript. WebCrypto runs cryptographic primitives. The Web Audio API decodes and re-encodes audio. Together they cover roughly everything a desktop image-or-document utility used to need C code for.

The product motivation is that for simple operations — converting a HEIC to JPG, compressing a PDF, decoding a JWT — sending the file to someone else's server is overkill. It introduces a wait, a trust dependency, and a real privacy concern. If we can do the same operation locally in 500 milliseconds, we should.

How to verify it for yourself

The nice thing about browser-only processing is that you don't have to trust us. Open the DevTools network tab in any tool on this site — DevTools → Network, or Cmd+Option+I /Ctrl+Shift+I. Drop your file in. Watch the network panel as the tool runs. You will see zero requests for the file. The only requests are the initial page load (HTML, CSS, JS, the occasional WebAssembly decoder) — none of those carry your data.

You can also disconnect from the internet after the page loads. Every tool will still work, because the entire pipeline is local. (Try it: load HEIC to JPG, then turn off Wi-Fi, then drop in a file.)

The actual pipeline, by category

Image converters and editors. The file is read via FileReader.readAsDataURL() or createImageBitmap(), decoded into a <canvas>, and re-encoded with canvas.toBlob() using the browser's native encoders. For formats the browser doesn't natively decode (HEIC, AVIF, TIFF), a small WebAssembly decoder runs in a Web Worker. All of this is on-device.

PDF tools. PDFs are read via FileReader.readAsArrayBuffer() and parsed with PDF.js (rendering) and pdf-lib (editing). Page-level operations (merge, split, rotate, extract) modify the PDF object structure directly — fast, no re-rendering. Operations that re-encode content (compress, watermark, to-image) render each page through PDF.js and re-encode.

GIF tools. Animated GIFs are decoded frame-by-frame with gifuct-js and re-encoded with gifenc, a fast WebAssembly encoder. Each frame goes through a canvas the same way single images do. Speed changes are even cheaper because they only adjust per-frame delays, not the pixels.

Audio. Audio Trimmer uses the Web Audio API to decode MP3, WAV, OGG, and (where supported) AAC/M4A, then a hand-rolled WAV serializer to produce the trimmed output.

Text and developer tools. These are pure JavaScript — sort, dedupe, format, parse, hash. WebCrypto handles the hash and signing primitives (MD5 is a small JavaScript implementation since WebCrypto removed it; SHA-1/256/384/512 use WebCrypto). JWT decoding is base64url plus JSON.parse. Regex testing uses the browser's built-in regex engine.

What this means in practice

What we do collect

Anonymous, aggregate usage analytics — which pages were visited, broad geographic region, device type — so we can prioritize tool improvements. We do not collect filenames, file sizes, file contents, or anything tied to a specific person. The full data we collect is described in our Privacy Policy.

The site is monetized by display ads served by Google AdSense. Ads are based on the page content and on coarse signals about the visitor (broad interests, region) — never on what you process. The ad code itself does not get access to files you drop in; those stay inside the tool's isolated processing pipeline.

Where to go next