Tools that run entirely in the browser, and the trade-offs behind them.
View all tags
The obvious doubt about a browser-based PDF tool is whether it can work without uploading anything.
It can. PDF is a structured container format; pages can be copied into a new document without ever rendering them. But a few limits need stating up front, or users hit a wall exactly when it matters.
When I started the pixel-art tool, the first idea was "just add a mosaic filter".
That does not work. A mosaic enlarges pixel blocks while keeping tens of thousands of colours, so you get a low-resolution photo, not pixel art. Real pixel art has two hard constraints: how many cells, and how many colours.
An SVG exported from a design tool comes in two sizes: the picture you see, and the file that actually exists.
An 800-byte icon can spend more than 500 bytes on metadata nobody asked for. But cleaning it up requires knowing which bytes are junk and which are load-bearing.
Two of the new tools have to produce files from nothing: one packs PNGs into a .ico, the other packs text into a .zip.
The usual move is to install a library for each. But both formats are less complicated than their reputation suggests.
A QR tool looks like the simplest thing: type text, draw black and white squares. Building it, I hit one pitfall choosing a library and another handling Chinese text.
The site is deployed on Cloudflare Pages, and the build command is just npm run build. The longer I use it, the clearer it is that static hosting is not "upload and forget" — a few details directly affect the result.
"No uploads, no backend, therefore secure" is only half true. Removing the server does eliminate a large part of the attack surface, but the risk moves to two places: the visitor's browser and the dependency chain.
"Will adding tools make the homepage slower?" was my own biggest worry. The answer is not to minify harder, but to separate two things: do not pay for a page you never opened, and do not make the first click wait.
A user reported: after compressing, they were not happy with the result and wanted to try another quality, but the button was greyed out, so they had to refresh the page.
My first thought was "user error". My second was "no, this is mine".
jSquash packages mozjpeg, libwebp, and oxipng into browser-ready WASM. The API looks simple: init() then encode(). Wiring it in, I hit three pitfalls.
The laziest image compressor is three lines: createImageBitmap to decode, draw to a canvas, canvas.toBlob('image/webp', 0.75). I built that prototype first, and then found it was nowhere near a "professional compression tool".
This site is hosted on Cloudflare Pages with nothing but build output — no server. Adding an "online tools" section starts with boundaries, not with a tech stack.