DEV Community: Shahrukh Khan

How I built 272 privacy-first tools with WebAssembly and no backend

Shahrukh Khan — Tue, 29 Sep 2026 07:41:26 +0000

Five weeks ago I started building a PDF compressor. Today the site has 272 tools and none of them upload your files to a server. This is what the architecture looks like, why I made those choices, and where it breaks.

The premise

Every "free online PDF compressor" I could find has the same shape: you upload your file, their server compresses it, you download it back. Their privacy policy says something like "files are deleted within 24 hours" and you either trust that or you don't.

You don't have to trust anything if the file never leaves your machine.

Browsers in 2026 can do this. Between WebAssembly, Web Workers, the Canvas API, and a handful of mature JS libraries, you can compress PDFs, convert HEIC to JPG, turn a MOV into an MP4, and run every developer utility you'd want, entirely client-side. So I did that, 272 times.

The result is toolspace.cloud — 272 browser tools across PDF, image, video, audio, converters, calculators, writing, and developer utilities. No signup, no upload, no ads.

The stack

Next.js 16 — static export for tool pages. Each tool is essentially an HTML file plus a JS bundle that lazy-loads whatever wasm library it needs.
ffmpeg.wasm — video and audio work.
pdf-lib — PDF construction (merge, split, watermark, page manipulation).
pdf.js — PDF rendering (for previews and PDF-to-image).
libheif-js — HEIC decoding (Safari has native support, other browsers don't).
Canvas API + OffscreenCanvas — image resize, convert, crop, filter.
Web Workers — every heavy operation runs off the main thread.
Service worker — caches wasm binaries after first load, so the second visit to any video tool is instant.

Nothing exotic. Everything on that list has been production-ready for at least a year.

Example 1: HEIC → JPG with ffmpeg.wasm

HEIC is the format iPhones save photos in. Every non-Apple platform hates it. There are two ways to convert it in the browser: libheif-js (fast, small) or ffmpeg.wasm (heavier but handles a wider format matrix and you probably already have it loaded for video tools).

Here's the ffmpeg.wasm version, which is what Toolspace uses when a user opens the "batch image converter" that supports HEIC alongside 20 other formats:

import { FFmpeg } from '@ffmpeg/ffmpeg';
import { fetchFile, toBlobURL } from '@ffmpeg/util';

let ffmpegInstance = null;

async function getFFmpeg() {
  if (ffmpegInstance) return ffmpegInstance;

  const ffmpeg = new FFmpeg();
  const baseURL = 'https://unpkg.com/@ffmpeg/core-mt@0.12.6/dist/esm';

  await ffmpeg.load({
    coreURL: await toBlobURL(`${baseURL}/ffmpeg-core.js`, 'text/javascript'),
    wasmURL: await toBlobURL(`${baseURL}/ffmpeg-core.wasm`, 'application/wasm'),
    workerURL: await toBlobURL(`${baseURL}/ffmpeg-core.worker.js`, 'text/javascript'),
  });

  ffmpegInstance = ffmpeg;
  return ffmpeg;
}

export async function heicToJpg(file, quality = 90) {
  const ffmpeg = await getFFmpeg();

  const inputName = 'input.heic';
  const outputName = 'output.jpg';

  await ffmpeg.writeFile(inputName, await fetchFile(file));

  await ffmpeg.exec([
    '-i', inputName,
    '-q:v', String(Math.round(31 - (quality * 0.31))), // ffmpeg's quality scale is inverted
    outputName,
  ]);

  const data = await ffmpeg.readFile(outputName);

  // Clean up the virtual FS so we don't leak memory across conversions
  await ffmpeg.deleteFile(inputName);
  await ffmpeg.deleteFile(outputName);

  return new Blob([data], { type: 'image/jpeg' });
}

Two things worth flagging:

ffmpegInstance is memoized. ffmpeg.wasm's load() is expensive (multi-MB wasm binary). Loading once per session and reusing across conversions is the difference between "usable" and "unusable."
You must delete files from the virtual FS. ffmpeg.wasm keeps an in-memory MEMFS. If you don't clean up, batch conversions leak memory until the tab dies.

Cross-origin isolation matters here too. To use multi-threaded ffmpeg (which is 3–5× faster), the page needs Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp headers. Without them, SharedArrayBuffer isn't available and you fall back to single-threaded.

Example 2: PDF merge with pdf-lib

PDF merge is the tool people search for most, and it's the most trivial to implement — which tells you something about how much of the "PDF SaaS" industry is glue code with a marketing budget.

import { PDFDocument } from 'pdf-lib';

export async function mergePdfs(files) {
  // `files` is an array of File objects from an <input type="file" multiple>

  const mergedPdf = await PDFDocument.create();

  for (const file of files) {
    const arrayBuffer = await file.arrayBuffer();
    const pdf = await PDFDocument.load(arrayBuffer, {
      ignoreEncryption: false, // fail loudly on password-protected PDFs
    });

    const copiedPages = await mergedPdf.copyPages(
      pdf,
      pdf.getPageIndices()
    );

    copiedPages.forEach((page) => mergedPdf.addPage(page));
  }

  const mergedBytes = await mergedPdf.save({
    useObjectStreams: true, // smaller output
  });

  return new Blob([mergedBytes], { type: 'application/pdf' });
}

That's the whole tool. Add a drag-and-drop UI on top and you have something SmallPDF would charge you a subscription for. The reason they can charge for it is that most users don't know pdf-lib exists.

Password-protected PDFs are the one gotcha. ignoreEncryption: false means you get an error you can catch and surface to the user ("this PDF is password-protected, unlock it first"). Setting it to true will silently produce broken output.

Where it breaks

Being honest about limits is the whole point of the project, so:

1. File size is bounded by browser RAM.
Chrome on a decent desktop handles ~500MB. Safari on iOS caps way lower. If you try to merge a 2GB PDF, the tab dies. Server-side tools don't have this ceiling.

2. First-load latency is real.
The multi-threaded ffmpeg.wasm build is ~30MB gzipped. First visit to a video tool takes 3–8 seconds to fetch and instantiate. Subsequent visits are instant (service worker), but that first hit is a real cost that server-side competitors don't pay.

3. No SharedArrayBuffer in embedded webviews.
Some in-app browsers (Facebook, Instagram, older WebViews) don't allow SharedArrayBuffer even with correct headers. Those users get the single-threaded ffmpeg build automatically. It works, it's just slower.

4. Battery.
Compressing a big video in a phone browser will heat the device and burn battery. A server would do it once and cache. There is no free lunch.

Why I still did it this way

Because the alternative is asking users to trust that a random "free PDF compressor" is actually deleting their files. And they shouldn't have to trust that. If the file physically never leaves the device, there is nothing to trust — there's just what the code does, which is verifiable in DevTools.

The trade-off is: I can't offer the biggest possible file sizes, and the first load is heavier. In exchange, the user's file is theirs.

Five weeks in, that trade-off feels right. Feedback welcome — especially from anyone who's built with ffmpeg.wasm at scale, because the memory-management edge cases are still where I lose the most sleep.

Building qurandaily.org: 37,000 pages statically prerendered with Next.js 15 + next-intl

Shahrukh Khan — Tue, 29 Sep 2026 07:36:10 +0000

Last week I shipped qurandaily.org, an ad-free Quran + hadith + duas site with content in six languages (English, Indonesian, Arabic, Urdu, Turkish, French). Every one of its ~37,000 pages is fully prerendered at build time. No SSR on the hot path. No database call between the reader and an ayah. In this post I want to walk through three decisions I had to make and the exact code / config for each, because the patterns generalize to any large multi-locale content site.

The three parts:

Static prerender for 6,236 records × 6 locales via generateStaticParams
Sitemap sharding to avoid the SWC minifier ceiling
Cloudflare Full mode with a self-signed 15-year origin cert

1. `generateStaticParams` at 6,236 × 6

The canonical content is 6,236 ayat. Each renders as its own URL, scoped by locale and surah slug:

/[locale]/quran/[surahSlug]/[verse]

Directory layout in the app router:

app/
  [locale]/
    quran/
      [surahSlug]/
        [verse]/
          page.tsx

The page.tsx exports two functions Next uses at build time to enumerate every route it should emit:

// app/[locale]/quran/[surahSlug]/[verse]/page.tsx
import { locales } from '@/i18n/config';
import { getSurahs } from '@/data/quran';

export const dynamicParams = false; // 404 anything not prebuilt
export const dynamic = 'force-static';

export async function generateStaticParams() {
  const surahs = await getSurahs(); // 114 surahs, each with ayat count
  const params: {
    locale: string;
    surahSlug: string;
    verse: string;
  }[] = [];

  for (const locale of locales) {          // 6
    for (const s of surahs) {              // 114
      for (let v = 1; v <= s.ayatCount; v++) { // 6,236 total
        params.push({
          locale,
          surahSlug: s.slug,
          verse: String(v),
        });
      }
    }
  }
  return params;
}

That yields 6 × 6,236 = 37,416 static routes for the Quran alone. Add hadith, duas, 99 Names, prayer-time city pages, and learning pages, and you're just under 40k emitted HTML files.

Two things worth noting:

dynamicParams = false is important. It means anything not in generateStaticParams returns a 404, which is what you want for a canonical corpus. No accidental live rendering.
getSurahs() reads local JSON derived from the quran.com Uthmani source. No network call at build. Content build time is roughly 90 seconds cold on a decent laptop, most of which is Next writing files, not data fetching.

2. Sitemap sharding (and the SWC minifier bug)

My first attempt at a sitemap used Next's app/sitemap.ts convention with all 37k URLs generated in one function. It built, but the build ran out of memory on my VPS during route compilation. The SWC minifier chokes on the resulting bundle around the 30k-URL mark — I saw the same OOM signature that's reported in a few open GitHub issues against next/sitemap.

Fix: one sitemap index at /sitemap.xml, six locale-specific sub-sitemaps behind it, each streamed by a route handler.

app/
  sitemap.xml/route.ts        // index, lists 6 child sitemaps
  sitemap-en.xml/route.ts
  sitemap-id.xml/route.ts
  sitemap-ar.xml/route.ts
  sitemap-ur.xml/route.ts
  sitemap-tr.xml/route.ts
  sitemap-fr.xml/route.ts

Index:

// app/sitemap.xml/route.ts
export const dynamic = 'force-static';

const LOCALES = ['en', 'id', 'ar', 'ur', 'tr', 'fr'] as const;
const BASE = 'https://qurandaily.org';

export function GET() {
  const body =
    '<?xml version="1.0" encoding="UTF-8"?>\n' +
    '<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">\n' +
    LOCALES.map(
      (l) => `  <sitemap><loc>${BASE}/sitemap-${l}.xml</loc></sitemap>`
    ).join('\n') +
    '\n</sitemapindex>\n';

  return new Response(body, {
    headers: { 'content-type': 'application/xml' },
  });
}

Per-locale child (simplified):

// app/sitemap-en.xml/route.ts
import { getSurahs } from '@/data/quran';

export const dynamic = 'force-static';

export async function GET() {
  const surahs = await getSurahs();
  const urls: string[] = [];
  for (const s of surahs) {
    for (let v = 1; v <= s.ayatCount; v++) {
      urls.push(
        `https://qurandaily.org/en/quran/${s.slug}/${v}`
      );
    }
  }

  const body =
    '<?xml version="1.0" encoding="UTF-8"?>\n' +
    '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">\n' +
    urls
      .map((u) => `  <url><loc>${u}</loc></url>`)
      .join('\n') +
    '\n</urlset>\n';

  return new Response(body, {
    headers: { 'content-type': 'application/xml' },
  });
}

Peak build memory went from an OOM at ~1.6GB to a steady ~600MB. Each locale sitemap ships as its own static file after the build. Google fetched all six within 24 hours of pushing.

3. Cloudflare Full mode + self-signed 15-year origin cert

The site is on a VPS with nginx in front. Cloudflare is in Full (not Full Strict) mode. In Full mode, Cloudflare requires TLS to the origin but does NOT validate the origin's certificate chain. That means a self-signed cert is fine — and if I make it 15 years long, I never have to think about it again. No certbot cron, no ACME failure notifications at 2am.

Generate the cert:

openssl req -x509 -nodes \
  -newkey rsa:2048 \
  -days 5478 \
  -keyout /etc/nginx/certs/origin.key \
  -out    /etc/nginx/certs/origin.crt \
  -subj   "/CN=qurandaily.org"

(5,478 days ≈ 15 years.)

nginx server block:

server {
    listen 443 ssl http2;
    server_name qurandaily.org www.qurandaily.org;

    ssl_certificate     /etc/nginx/certs/origin.crt;
    ssl_certificate_key /etc/nginx/certs/origin.key;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    root /path/to/build/out;
    index index.html;

    location / {
        try_files $uri $uri/ $uri.html =404;
    }

    # long-cache for hashed assets
    location /_next/static/ {
        add_header Cache-Control "public, max-age=31536000, immutable";
    }
}

Two things Cloudflare handles on top:

The public-facing TLS cert (auto-renewed by Cloudflare).
Edge caching. Because every response is a static file with a stable URL, the default cache rules do exactly what you want.

If you want Full Strict later, swap the self-signed cert for a Cloudflare Origin CA cert (also free, also 15-year) — same config, one file swap.

Wrapping up

Static prerender is the boring correct answer for content that doesn't change. The whole build ships as HTML files, the CDN does the hard work, and you spend zero time maintaining a runtime. If you want to see the output, the site is at qurandaily.org — ad-free, no login, no tracking, six languages. Feedback on the render setup or the edge config welcome, especially if you've hit the SWC sitemap issue and solved it differently.