DEV Community: Fahad Farid

How we audit local PDF processing (and what "no upload" actually proves)

Fahad Farid — Sun, 18 Oct 2026 19:45:22 +0000

Tags: javascript, webdev, privacy, tutorial

"No upload" is a claim. Anyone can write it under a button. So here's how we actually check it on ToolVero — and, just as important, what the check can't prove.

Step 1: grep the source for upload mechanisms

The blunt version of the audit is a static source review. We took all 74 public tool pages, their inline scripts, and the 8 first-party scripts they reference, and searched for the four ways a browser page can send data out: fetch(), XMLHttpRequest, WebSocket, and sendBeacon.

Result: no direct call to a ToolVero document-processing upload endpoint anywhere in tool code. That's the finding behind the "Private browser processing" badge — 74 pages checked, 42 of them file tools, zero first-party upload paths.

But a static review has a defined edge, and we publish it: it doesn't inspect third-party library internals, it doesn't observe runtime network traffic, and it doesn't mean the pages make no network requests at all. A page can load a library from a CDN, fire analytics, and serve ads — none of which is your file going to our server, but all of which is network activity. The badge wording says exactly this: the file isn't sent to a ToolVero processing server by the tool itself.

Step 2: design the exfiltration out, don't promise it away

The stronger audit pattern is clean-by-construction. Our Image Metadata Remover doesn't promise "we won't keep your EXIF data" — it makes keeping it structurally impossible. The pipeline decodes the image with createImageBitmap, rasterises it to a canvas, and rebuilds a fresh PNG that retains only the signature plus IHDR, IDAT and IEND chunks. There is no chunk in the output where EXIF, GPS, XMP or thumbnails could hide, because the output is assembled from pixels, not copied from the source container.

When the design removes the possibility, the audit only has to verify the design — a much smaller claim to defend than "trust our servers."

Step 3: publish what the audit finds, including the fixes

An audit that never finds anything isn't an audit, it's marketing. Ours found a real one: the Word-to-PDF converter was inserting HTML returned from a DOCX conversion library straight into the page, and that library's own docs warn its output isn't sanitized. We fixed it by rebuilding only a limited set of text, table and image elements — no script elements, no event handlers, no styles, no unsafe URL attributes carried through. Some advanced DOCX formatting gets dropped as a result, and we say so on the page.

The audit page also lists remaining work in plain text: at least 19 file-tool pages still load externally hosted library scripts, analytics and advertising scripts are present, and there's been no independent penetration test or live network capture with sample files. That's the current boundary of what we know.

Step 4: keep the categories separate

This is the part most "privacy" pages fudge. On our Trust Center we keep four things in separate boxes: the privacy design (browser-first processing), the technical audit (the source review above), third-party scans (SSL Labs, SecurityHeaders, Sucuri — transport and header checks, dated, with their own limits), and formal certification (which we don't claim to hold). A scan result is not a certification. An internal review is not a penetration test. Saying which is which is the whole point.

The takeaway for builders

If you ship browser-local tools, audit like this:

Grep for exfiltration primitives (fetch, XHR, WebSocket, sendBeacon) across every page and first-party script. It's crude and it catches the obvious.
Prefer clean-by-construction pipelines — rebuild outputs from primitives so the sensitive data can't survive even if you wanted it to.
Publish the scope box: what you checked, what you explicitly didn't, and what's still open. The full audit is dated October 10, 2026, and it reads like a lab notebook, not a badge.
Never let marketing outrun the audit. Our commitment is mechanical: if a tool ever moves from local to server-side processing, its privacy explanation changes with it — no stale claims.

"No upload" is only as strong as the audit behind it. Ours is public, dated, and honest about its edges — which is exactly why we'd rather you read it than trust it.

Merging PDFs in the browser: no server, no upload

Fahad Farid — Sat, 17 Oct 2026 15:23:56 +0000

Merging PDFs sounds like server work, but the PDF format is just a structured binary file — and libraries like pdf-lib can read and write it entirely in JavaScript. So the merge can happen in the tab, with your documents never uploaded anywhere.

The whole trick

import { PDFDocument } from 'pdf-lib';

async function mergePDFs(files) {
  const merged = await PDFDocument.create();
  for (const file of files) {
    const pdf = await PDFDocument.load(await file.arrayBuffer());
    const pages = await merged.copyPages(pdf, pdf.getPageIndices());
    pages.forEach(page => merged.addPage(page));
  }
  const bytes = await merged.save();
  return new Blob([bytes], { type: 'application/pdf' });
}

That's genuinely it: load each file into memory, copy its pages into a fresh document, save. copyPages preserves vector content, fonts, and images — the output isn't a rasterized screenshot, it's a real PDF.

The gotchas

Encrypted PDFs: pdf-lib can't open password-protected files silently. Pass the password via the load options, or handle the failure gracefully and tell the user why.
Memory: everything lives in RAM. Fine for typical documents; on mobile, warn before merging hundred-page scans.
Forms and annotations come along with copyPages. If you need a flat, uneditable result, flatten form fields before saving.
Page sizes: mixed source sizes are preserved per page, which is usually what you want — don't "normalize" unless the user asks.

Why client-side wins here

PDFs are often sensitive — contracts, invoices, ID scans. The privacy argument writes itself: no upload means no transit interception, no server retention policy to trust, and it works offline once the page loads.

The same approach powers the Merge PDF and Compress PDF tools on ToolVero — free, no signup, files never leave your browser.

Your password generator is probably using Math.random(). Stop.

Fahad Farid — Thu, 15 Oct 2026 08:55:47 +0000

Math.random() is not cryptographically secure. Its output is deterministic given the internal state, which means passwords generated with it are guessable in principle. Any password or token generator must use the Web Crypto API instead: crypto.getRandomValues().

The correct core

function securePassword(length = 20) {
  const charset =
    'ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz23456789!@#$%^&*';
  const bytes = new Uint8Array(length * 2);
  crypto.getRandomValues(bytes); // CSPRNG, provided by the OS
  const limit = 256 - (256 % charset.length);
  const out = [];
  for (const b of bytes) {
    // Rejection sampling: skip bytes that would cause modulo bias
    if (b < limit && out.length < length) out.push(charset[b % charset.length]);
  }
  return out.join('');
}

Two details worth understanding:

crypto.getRandomValues() pulls from the operating system's cryptographically secure random number generator — the same source TLS uses. It cannot be seeded or predicted from JavaScript.
Rejection sampling fixes modulo bias. If your charset length doesn't divide 256 evenly, a naive byte % charset.length makes some characters slightly more likely. Discarding out-of-range bytes keeps the distribution uniform. (In production, loop and refill until the password is full rather than hoping one buffer is enough.)

How strong is it?

With a 70-character set and 20 characters, you get log2(70^20) ≈ 122 bits of entropy. That's beyond brute force for any realistic adversary — length plus a real CSPRNG is the entire game.

The checklist

Never Math.random() for secrets. Ever.
Generate locally — a password that never touches a network can't be intercepted in transit or logged by a server.
Don't get clever with "memorable" patterns that shrink the search space.

Want one without writing it yourself? The Password Generator on ToolVero uses exactly this approach — everything runs locally in your tab.

How I shrink images 80% without a server

Fahad Farid — Wed, 14 Oct 2026 12:21:24 +0000

Every image optimizer site asks you to upload your photos first. But your browser can already decode, resize, and re-encode images — so the whole compression pipeline can run in the tab, with the original file never leaving your device.

The pipeline

Three steps, all client-side:

Decode the uploaded file into pixels (createImageBitmap).
Draw it onto a canvas at the target dimensions — this is where resizing happens, and it's the biggest win.
Export with canvas.toBlob() at a chosen quality and format.

async function compress(file, maxWidth = 1600, quality = 0.8) {
  const bitmap = await createImageBitmap(file);
  const scale = Math.min(1, maxWidth / bitmap.width);
  const canvas = document.createElement('canvas');
  canvas.width = Math.round(bitmap.width * scale);
  canvas.height = Math.round(bitmap.height * scale);
  canvas.getContext('2d').drawImage(bitmap, 0, 0, canvas.width, canvas.height);
  return new Promise(resolve =>
    canvas.toBlob(resolve, 'image/webp', quality)
  );
}

Why it works so well

Resizing dominates. A 6000px phone photo displayed at 1200px carries roughly 25x the pixels it needs. Nothing beats deleting pixels you were never going to show.
Modern formats. WebP at quality 0.75–0.85 is visually near-identical to the source JPEG for photographs, at a fraction of the size.
Metadata goes free. The decode/re-encode round-trip drops EXIF segments automatically — the output is pixels only.

The gotchas

Screenshots and flat graphics: lossy compression smears text and sharp edges. Use WebP lossless or PNG for those.
Transparency: JPEG has no alpha channel. If the source has transparency, export WebP or PNG instead.
Orientation: modern browsers apply EXIF orientation when decoding via createImageBitmap, but verify on Safari before you ship.

No upload means no waiting on a server round-trip either — on a decent laptop this runs in milliseconds per image.

I build ToolVero, 70+ free tools that run entirely in your browser. The same pipeline powers the Image Compressor and Image Resizer — try them on your own photos.

How I strip photo metadata without a server

Fahad Farid — Tue, 13 Oct 2026 20:58:02 +0000

Your phone embeds a small diary in every photo: GPS coordinates, camera model, timestamps. Most “metadata remover” sites ask you to upload that diary to their server first — which rather defeats the purpose.

I build ToolVero, a set of 70+ free tools that run entirely in your browser, and the image metadata remover takes the opposite approach: the photo never leaves the device. Here’s the whole trick.

The method: decode, then re-encode from pixels

EXIF, GPS and XMP all live in the JPEG’s metadata segments — they are not part of the image data itself. So instead of surgically deleting segments, we throw the container away:

Decode the uploaded JPEG into a canvas bitmap (pixels only — the browser’s image decoder does not carry EXIF into the bitmap).
Create a fresh PNG from those pixels with canvas.toBlob('image/png').
Offer that PNG as the download, under a neutral filename.

A PNG produced this way contains only IHDR, IDAT and IEND chunks. There is simply nowhere for EXIF to hide, because we never copied the original file’s segments — we re-created the image from raw pixels.

const img = await createImageBitmap(file);   // pixels only, no EXIF
const canvas = document.createElement('canvas');
canvas.width = img.width;
canvas.height = img.height;
canvas.getContext('2d').drawImage(img, 0, 0);
const clean = await new Promise(r => canvas.toBlob(r, 'image/png'));
// `clean` is a fresh PNG: IHDR + IDAT + IEND, zero metadata segments

Why the output is clean by construction

PNG has no EXIF segment to preserve, and this method never copies the original file’s metadata segments at all — only the pixels. So EXIF, GPS and XMP have nowhere to survive. (Re-encoding to JPEG via canvas is equally clean, since canvas never writes EXIF — but PNG is the safer default because the format itself can’t carry the metadata.)

Why client-side matters

The privacy win isn’t just the stripped file — it’s that the stripping happens on your machine. No upload means no transit interception, no server logs, no “we delete after 24 hours” promises to trust. For a privacy tool, the architecture is the feature.

Try it on your own photos: Image Metadata Remover — everything runs locally in the tab.