That was the point. A tool that promises "your files never leave your device" shouldn't be quietly reporting on you either.

It also means I had no idea who uses it.

The only numbers I have are the ones every host sees anyway: Cloudflare's request logs, summed per day, with no cookies and no fingerprinting. So I took 30 days of them and tried to answer one question: how many of my "visitors" are actually people?

Here's what the dashboard says:

36,000 visits for a side project sounds amazing. It isn't true. Let's take it apart.

Clue 1: the second most popular file isn't a page

Sort requests by path and the top of the list is:

robots.txt is the second most requested file on the site. No human opens it on purpose. That's 3,000 requests from crawlers asking whether they're allowed in. (They are. I welcome search engines and AI answer engines, because that's how people find a free tool.)

Clue 2: the "browsers" aren't browsers

Cloudflare groups page views by browser. The biggest group isn't Chrome:

"Unknown" is three times bigger than Chrome. The user-agent list explains it:

• Petalbot (Huawei's search crawler): 10,290 page views. My single biggest "visitor".
• SemrushBot (an SEO tool): 5,150.
• An iPhone on iOS 13, from 2019, with 2,760 page views. That exact user agent is a favourite of scrapers.
• msh-pdfmin/1: 2,720. I have no idea what this is. It reads PDFs, apparently.
• ElevenLabs' crawler, Amazonbot, Googlebot and Bingbot after that.

Across all requests, 11,790 had no user agent at all, and 14,700 came from Headless Chrome: Chrome with no screen, which is what scrapers and test bots run.

Clue 3: Singapore loves my site (it doesn't)

Page views by country:

Singapore, with six million people, sends ten times more page views than India, where I live and where most people I know use the site.

But the best clue is the ratio of requests to page views, because a real visit pulls in fonts, scripts and, if you use a tool, its engine:

Indian visitors load 22 files per page: they're opening tools and using them. "Singapore" loads one and a half: fetch the HTML, leave. That's what a crawler in a data centre does, and Singapore is full of data centres.

Clue 4: bots looking for a server that doesn't exist

Fizzdoc has no backend. No database, no login, no API, no WordPress. Bots don't know that, so they keep checking:

wp-config.php is where WordPress keeps its database password, and .old and .bak are the backup copies people forget to delete. Someone is checking my static site for all three.

Add the rest of the guessing and 30,650 requests got a 4xx error: one in nine requests was for something that never existed.

My favourite part of having no backend: none of this matters. There's nothing to find.

So how many people? Count the downloads, not the visits

Page views are easy to fake. Downloading an AI model is not, and bots don't bother, because they never run the tool.

Fizzdoc's AI tools download a model the first time you use them, and the browser keeps it afterwards. So the bandwidth spent on model files is a rough count of real people who actually used an AI tool:

• Phone background removal. The model is 4.57 MB and served 1.19 GB: about 260 downloads.
• Desktop background removal. The model is about 100 MB, split into 20 MB parts because Cloudflare Pages won't host a file over 25 MB. Each part served 1 to 1.7 GB: roughly 50 to 80 full downloads.
• Speech to text. The encoder is 10 MB and served 608 MB: about 60 transcriptions.

These are rough. A download that stops halfway still counts, and one person on two devices counts twice. But the scale is clear: tens of thousands of "visits" in the dashboard, a few hundred real uses of the heavy tools. Add the people using light tools that need no model (compress, merge, convert) and the real number of people is in the low thousands, close to the 17,490 "unique visitors" at best, and nowhere near 36,000 visits.

Honestly? A few thousand people a month trusting a side project with their files is more than I expected. I just wanted the real number.

Bonus: my CDN wasn't caching my heaviest files

One more number bothered me: only 41.65% of requests came from Cloudflare's cache, and only 11.82% of the bandwidth (2.15 GB of 18.23 GB).

For a site that is 100% static files, that's low. The headers explain it:

$ curl -sI https://fizzdoc.com/assets/index-....js
cache-control: public, max-age=31536000, immutable      <- cached for a year

$ curl -sI https://fizzdoc.com/bg/birefnet-lite/model.onnx.part0
cache-control: public, max-age=0, must-revalidate       <- re-checked every time
cf-cache-status: DYNAMIC

The JavaScript is cached perfectly. Its filename contains a hash of its contents, so it can be cached "forever". But the model files, the heaviest files on the site, had no cache rule, so 16 GB went out uncached.

Visitors barely noticed, because the browser keeps a model after the first download. But it's the wrong default, and it's a few lines in a _headers file. That's the next post: the fix, and the before and after.

What I learned

1. Dashboard visits are not people. On a small site, bots can easily be most of the traffic. Don't put "36k visits" on a slide.
2. Your top paths are a free bot report. robots.txt, wp-config.php and 404s tell you who's knocking.
3. Requests per page view is a great bot detector. People load assets; crawlers fetch HTML and leave.
4. Count something bots can't fake. For me it's model downloads. For you it might be a form submit, an export or a signup.
5. You don't need tracking to learn a lot. Aggregate server-side numbers answered most of my questions without a single cookie.
6. Check your cache headers. A static site with a 42% cache hit rate has a config bug, not a traffic problem.

Fizzdoc is free and open source. It runs 74 PDF, photo and audio tools entirely in your browser, in 17 languages.

• Try it: fizzdoc.com
• Code: github.com/kingrishabdugar/fizzdoc

If you've been through your own logs and found something weird, tell me in the comments. And if you think my real-human estimate is too high or too low, I'd love to know how you'd measure it.

Most "free online PDF tool" sites have the same architecture: your file goes up to their server, gets processed, and comes back. The privacy policy says they delete it after an hour. You have to take their word for it.

I learned this as the family's unofficial IT person. Every few weeks, someone sends me an Aadhaar scan or a bank statement and asks me to "make it smaller" or "unlock it". I kept uploading other people's documents to sites I knew nothing about, and at some point that stopped feeling okay.

After my first two posts on Fizzdoc, a close friend asked me some version of "but how do I know it really doesn't upload?" This post is the long answer.

So for Fizzdoc I wanted a site that can't see your file, by design. The browser itself won't let the page send it anywhere.

Fizzdoc now has 74 tools (PDF, Word, Excel, PowerPoint, images, audio), 16 languages and about 1,200 pages, and it has no backend at all. This post is about the design decisions that make that work, and the trade-offs I accepted.

Constraint 1: the page is not allowed to talk to anyone

Every page ships this Content Security Policy (in a <meta> tag, which the browser enforces just like a header):

default-src 'self'; script-src 'self' 'wasm-unsafe-eval'; connect-src 'self'; ...

connect-src 'self' is the important part. fetch, XMLHttpRequest, WebSockets, sendBeacon: the browser blocks all of them unless they go to fizzdoc.com itself, and fizzdoc.com is just static files. So even if one of the many open-source libraries had a bug or a malicious update, it couldn't send a document anywhere.

That one line shaped everything else:

• No CDNs. Fonts, WebAssembly engines and AI models are all served from the same origin.
• No analytics scripts. Even when Cloudflare injected its own analytics beacon, the CSP blocked it, because a script that isn't from the site can't run. (I switched that beacon off too; traffic numbers come from Cloudflare's server-side stats instead.)
• It is testable. The Playwright suite (about 1,250 browser tests) runs real jobs and fails if any request leaves the origin.

Constraint 2: no server, so the build does the work

There is no server to render pages, so a build step renders all of them ahead of time. One TypeScript file lists every tool (name, copy, FAQ, search keywords), and the build turns it into a static HTML page per tool per language: about 1,200 pages, each with its own title, structured data (FAQ, HowTo, breadcrumbs), hreflang links and sitemap entry.

The first load is small because each page only ships what it needs:

Everything heavy loads only when you use the tool that needs it, through dynamic import().

Each job gets its own throwaway worker

The PDF tools are qpdf compiled to WebAssembly. Every job gets a fresh Web Worker, which is terminated when the job ends. That keeps the page responsive, and the file and any password disappear with the worker.

Other engines follow the same pattern: pdf.js and pdf-lib for rendering and editing, Tesseract (WASM) for OCR, Whisper (through Transformers.js) for speech to text, and BiRefNet on ONNX Runtime Web (WebGPU when available, WASM otherwise) for background removal.

Big models on a host with a 25 MiB file limit

Cloudflare Pages refuses any file over 25 MiB. The background model is about 100 MB and the WebGPU build of ONNX Runtime is 27 MB.

So the build splits them into 20 MiB parts. On first use the worker downloads the parts, joins them, and keeps the result in Cache Storage. After that the tool starts instantly, and it works with the internet off. The build also fails if any output file goes over the limit, after one deploy failed on it.

Offline without breaking updates

A service worker makes every tool work offline after one visit. The rules are deliberately boring:

• Pages: network first, cache as a fallback. Online visitors always get the latest page.
• Hashed assets (/assets/index-abc123.js): cache first. A hashed file never changes, so the cached copy is always right.
• Old files are never deleted. A page cached by an older version still needs its older assets.
• Models are excluded. Their tools manage their own caches.

A page that was never opened shows a small "needs the internet once" page in your language instead of the browser's error screen.

Hard parts that come from having no server

Phones run out of memory, silently. The first version of the background remover crashed Chrome on a 6 GB Android phone ("Aw, Snap!" at 5%). A tab gets far less memory than the phone has, and there's no error to catch. Phones now use a 4.6 MB model instead of the 100 MB one.

iPhone canvases have a size limit (about 16.7 million pixels). The Photo Editor tries full size first and falls back to the largest canvas the device allows.

Fonts couldn't be data: URLs. Vite inlines small files as data: URLs, my own CSP refused them, and the CSP-violation test caught it before it shipped.

"Share to WhatsApp" can't make a sticker. A web page can't add stickers to WhatsApp. A shared file arrives as a photo, so the page shows WhatsApp's own "Create sticker" steps instead of a button that lies.

The editor is just pixel maths

The newest tools, the Photo Editor and the Collage Maker, use no image library. Brightness, contrast, saturation and warmth are a short loop over the pixels. Every edit redraws from the original photo, so edits never pile up blur. Doing it in plain code instead of ctx.filter means every browser gives the same result, and unit tests can check it.

What it costs, and what 30 days of traffic look like

Fizzdoc runs on Cloudflare's free plan. Hosting costs me nothing, because every page and every AI model is just a static file. These are Cloudflare's own server-side numbers for the last 30 days (there is no analytics script on the site, so this is all I can see):

A few things I didn't expect:

• A big share is bots. Search crawlers (Googlebot, Applebot, Petalbot, Semrush) and AI crawlers show up all over the user-agent list. I welcome them in robots.txt, but it means "42k visits" is not 42k people. Treat these as upper bounds.
• Most of the bandwidth is AI models, not pages. The pages are tiny; the 10 GB is almost all background-removal and Whisper model files that visitors download once and then keep in their browser cache.

• Bots keep looking for a backend that doesn't exist. Hundreds of requests for /.env, /wp-config.php, /api/ and /login. There is nothing to find, since there's no server, database or secrets behind the site.
• Visitors come from everywhere. The United States, India, Singapore, South Korea, Australia and Germany lead, and the page is in 16 languages.

Trade-offs I accepted

• Your device does the work. A 300-page scan OCRs slower on an old phone than on a server.
• Some formats aren't possible yet. PowerPoint to PDF and old .doc/.xls files aren't supported.
• One-time downloads. The AI tools download their model once (the page shows the size first).

Try it, break it

• Site: https://fizzdoc.com
• Code (Apache-2.0): https://github.com/kingrishabdugar/fizzdoc
• Check it yourself: open DevTools → Network, run any tool, and watch nothing leave.

If you build something similar, the one decision I'd copy is the CSP. It turns "we don't upload your file" from a promise into a property of the page. And if Fizzdoc saved you an upload, a star on GitHub helps more people find it.

For a product shot, that's annoying. For a passport photo, a signature, or a client's photo, it's a bit more than annoying.

So I added a background remover to Fizzdoc, my open-source toolkit where every tool runs inside the browser tab. It now does:

• Photos: Remove Background, saved at the photo's own resolution as PNG, JPG or WebP.
• Animated GIFs: Remove GIF Background, every frame, same timing, same loop.
• Videos: Remove Video Background, every frame, with the sound kept.
• WhatsApp stickers: WhatsApp Sticker Maker, a 512 × 512 WebP with a white outline, kept under 100 KB, with words in fun fonts and emoji you drag into place.

You can keep the background clear, or put white, any colour, a blur or another photo behind. It's free, there's no sign-up, no watermark, and no limit on how many photos you do. The size limit comes from your device's memory, not from me.

And the photo never leaves your device. Not "we delete it after an hour". It just never goes anywhere.

Below is how it works, and what broke along the way.

The rule: nothing gets uploaded, and you can check

Fizzdoc is a static site on Cloudflare Pages. There's no backend, so there's nothing that could receive a file. The page also ships a Content Security Policy with connect-src 'self', which means the browser itself blocks the page from talking to any other website.

That rule shaped everything below. No CDN for the model, no hosted inference API, no "just this one request". Open DevTools, go to the Network tab, remove the background, and you'll see the model files coming from fizzdoc.com and nothing going out.

Picking a model

I wanted three things:

1. Good edges on hair and fur, because that's where background removers usually show their seams.
2. Small enough to download once into a browser.
3. A licence that lets anyone use the result, including for work.

I went with BiRefNet (MIT licence), the lite variant, using the 512 × 512 ONNX export by studioludens. I store its big weight tensors as 16-bit floats and cast them back to 32-bit when the model loads, which halves the download to about 100 MB without changing the maths it runs.

For phones there's a second model, U²-Net small (Apache-2.0), just 4.6 MB. I learned this one the hard way: someone sent me a screenshot of an early version on a 6 GB Android phone, where Chrome killed the tab at 5% ("Aw, Snap!"). A browser tab on a phone gets far less memory than the phone has, and when it runs out there's no error to catch, the tab just dies. So now phones always use the small model, and the page says so ("for the cleanest edges on hair and fur, use a laptop"). If the big model ever crashes a tab on a laptop too, the page remembers it for 30 days and uses the small one there.

And for laptops with a graphics chip there's the opposite: a Sharper edges (hair, fur) button. It reruns the photo through a 1024 × 1024 export of the same BiRefNet-lite model (onnx-community, MIT). It's a one-time 135 MB download and needs WebGPU, so it's never offered on phones. If the device can't manage it, you keep the result you already had.

Running it: WebGPU when it can, CPU when it can't

The model runs with ONNX Runtime Web inside a Web Worker, so the page never freezes.

• If the device has a graphics chip with WebGPU, the model runs there. This is the fast path.
• If WebGPU isn't there (or the driver says no), the same model runs on the CPU through WebAssembly.
• If that fails too, usually because the device ran out of memory, the small U²-Net model takes over.

So the chain is GPU, then the same model on CPU, then the small model. Nobody gets an error just because their laptop is old.

Two fun problems with "self-host everything"

Cloudflare Pages has a 25 MiB limit per file. The model is about 100 MB and ONNX Runtime's WebGPU build is a 27 MB .wasm. So both live on the server as 20 MiB parts: the models are split by a small script when I add them, and the runtime is split at build time. The worker downloads the parts, joins them, and keeps the result in the browser's Cache Storage, so the next time it starts straight from there, even with the internet off. The build also fails if any file it writes goes over 25 MiB, after one deploy failed on it.

A runtime that exists in pieces. ONNX Runtime normally fetches its .wasm as one file. Mine exists just as parts on the server, so the worker joins them from Cache Storage and hands the bytes to the runtime directly with ort.env.wasm.wasmBinary. It needs no extra hosting and no change to the security policy.

The part I'm proudest of: full resolution from a 512 px model

The model looks at your photo squeezed to 512 × 512 and returns a soft mask. If you stretch that mask back over a 4000 × 3000 photo, the edges look like they were cut with a butter knife.

So the mask goes through two classic image-processing filters, both plain arithmetic on typed arrays in the worker:

1. Fast guided filter (He and Sun, 2015). It uses the photo itself as a guide to snap the blurry mask onto the real edges, so hair follows the actual strands. The fit is computed on a smaller copy (up to 1280 px) and then applied to every pixel of the full photo in one pass.
2. Blur-fusion foreground estimation (Forte, 2021). Edge pixels are a mix of your subject and the old background. Put a cut-out on a new colour without fixing that, and you get a faint halo of the old background. This step estimates the subject's true colour at the edges, so the new background looks like it was always there.

By default the result is saved at your photo's own size: your own pixels, with a cleaner mask.

When the AI gets it almost right

It's an AI model, so a busy background or a subject that blends into it can confuse it. For photos there's a small set of touch-ups:

• Erase / Restore brush, with Undo, Redo and Zoom for careful work on a phone.
• Tap to remove and Tap to keep: one tap picks the whole connected area of a similar colour and removes it, or brings it back.
• Shadow and a white Outline, if you want the cut-out to stand out.
• Crop: the whole photo, fit to the subject, or a square around the subject for online shop listings.
• Hold to see the original, to compare before and after.

GIFs: every frame, same rhythm

Animated GIFs are sneaky. Many frames aren't full pictures, just small patches drawn over the previous frame, with rules ("disposal methods") about what to clear afterwards.

• gifuct-js (MIT) decodes the frames, and Fizzdoc composes each one into a full picture the way a browser would show it.
• Each frame goes through the same model (in a faster mode, since there can be dozens).
• gifenc (MIT) writes the new GIF, keeping every frame's delay and the loop.

One catch: a GIF pixel is either fully see-through or fully solid. So on a clear background the edges are a little sharper than in a PNG. Pick a colour or a photo behind and the soft edges are back.

Videos: every frame, sound kept

For video, Mediabunny (MPL-2.0) reads the file and the browser's own WebCodecs encoder writes the new one. Every frame goes through the model and gets its new background, and the soundtrack is carried over.

The output is MP4 (H.264) if the browser can handle it; otherwise, it's WebM (VP9). Before you start, the page shows a preview frame and an estimate of how long the whole clip will take on that device.

What does "no background" mean for a video? Truly see-through video would need the encoder library to start helper workers from blob: URLs, which my page's security policy blocks, and most players can't show it anyway. So "None" gives you a green screen, which any video editor removes in one click. I chose to keep the policy strict rather than loosen it for one feature.

Stickers: words, emoji, and the last step in WhatsApp

The WhatsApp Sticker Maker starts from the same cut-out. It squares it to 512 × 512, adds a white outline, and keeps the WebP under 100 KB by lowering the quality step by step until it fits.

On top of that, you can add words in five styles (Funny, Cute, Cozy, BIG, and Serious) and emojis. Each one is a layer you drag, pinch, resize and rotate, on a phone or with a mouse. The fonts are self-hosted like everything else: Bangers, Kalam, Teko and Inter, with Baloo 2 covering Hindi letters. Emoji are drawn with your device's own emoji font.

One fun bug on the way: Vite inlines small files as data: URLs, and a few of the font files were small enough. My own CSP (default-src 'self') refused them, and the end-to-end test that fails on any CSP violation caught it before it shipped. Fonts are now always separate files.

One limit, though. A web page can't add a sticker to WhatsApp, and a sticker shared from the browser arrives as a normal photo. So instead of a "Share to WhatsApp" button that doesn't do what it says, the page shows WhatsApp's own steps: save the sticker, then in any chat tap Stickers › Create and pick it. On iPhone there's a "Save to Photos" button, because downloads go to Files and WhatsApp picks stickers from Photos.

What it's like on low-end phones

I care about this a lot because many people open Fizzdoc on Android phones.

• Phones always get the small model, so it works rather than crashes. Edges are a bit softer than on a laptop, which is a trade I'll take every time.
• The worker keeps the page responsive while it thinks.
• The model downloads once (the page shows the progress in MB). After that it starts right away, and it keeps working with Wi-Fi and mobile data off, which is also the easiest way to check that nothing is uploaded.
• Videos give you a time estimate first: short clips are fine, long ones are a laptop job.

Things it doesn't do (yet)

• Truly transparent video (see above, green screen instead).
• Many photos in one go: the background remover takes one photo at a time.
• Several photos in one sticker. That's next.

Credits

None of this would exist without these people and projects. Thank you:

The full licence texts are in Fizzdoc's third-party licences.

Try it, break it, tell me

• Photo: https://fizzdoc.com/remove-background/
• GIF: https://fizzdoc.com/remove-gif-background/
• Video: https://fizzdoc.com/remove-video-background/
• WhatsApp sticker: https://fizzdoc.com/whatsapp-sticker-maker/
• Code (Apache-2.0): https://github.com/kingrishabdugar/fizzdoc

It's part of a bigger toolkit of 68 free tools (PDF, Word, Excel, PowerPoint, images and audio), all running in your browser, in 16 languages. If something looks off on your device, there's a "Report it" link on every tool. And if you like it, a star on GitHub genuinely makes my day.

It took six minutes.

Six. On my laptop the same kind of job took about a second. The link was already out in public, so somewhere out there, people were staring at a progress bar that didn't exist and thinking "nice project, Rishab."

I'll tell you how I fixed it. But first, what this thing even is, and why I think it fits this year's Hacktoberfest theme, "AI belongs to everyone", better than I planned.

What is Fizzdoc?

Fizzdoc is 64 tools for PDF, Word, Excel, PowerPoint, images and audio. Merge, compress, convert, edit, redact, OCR, cut an MP3, turn a voice note into text. The usual suspects, in 16 languages.

None of it uploads your file, though. There's no backend. Not a small one, not a "we only keep it for an hour" one. Nothing. It's a static site, and every job runs inside your browser tab, on your own device.

Most "free PDF" sites work like this: you send them your passport scan (or your Aadhaar card, if you're in India), they send you back a slightly smaller one, and you hope for the best. That always felt like a strange deal for jobs a phone can do on its own. So I built the other version.

Oh, and it runs an open-weight AI model (Whisper) right in the tab to turn audio into text. No API key, no GPU, no server. If AI belongs to everyone, it should also run on everyone's phone.

It's open source (Apache-2.0): github.com/kingrishabdugar/fizzdoc. Everything in this post is in that repo, and every number comes from the code or something I actually measured.

Where Fizzdoc fits

The open-source world already has great PDF tools, and I've used several. Some are big platforms you self-host with Docker and run for a whole team, with pipelines, APIs and logins. Some are lean, browser-only PDF kits. Both are good at what they do.

Fizzdoc makes a different bet:

• Nothing to install. Not even Docker. Open a link on any phone or laptop and it works. That matters when the person who needs to unlock a PDF is your dad, not your homelab.
• Not just PDF. 30 PDF tools, 14 for images, 14 for Word, Excel and PowerPoint, and 6 for audio, including speech to text and subtitles. Plus developer odds and ends like Excel to JSON and Mermaid to PNG.
• Your language, not just English. 16 languages, from Spanish, French, German and Portuguese to Hindi, Bengali, Tamil and Telugu, each with its own URLs, so people can find it by searching the way they actually talk.
• Built for cheap phones first. More on that below, because I learned it the hard way.
• Privacy you can verify. A strict CSP and a test that fails if any request leaves the site.

If you need automation pipelines or an admin panel for your company, a self-hosted platform is the right call. If you need to shrink a photo to 50 KB for a government form on your phone in the next 30 seconds, that's what this is for.

The whole thing on one slide

Three layers, and only the last one ever touches your file.

Build time. One TypeScript file, src/site.ts, describes all 64 tools: slug, formats, options, page text. A renderer turns that into about 1,050 plain HTML pages (64 tools × 16 languages, plus a few extras), with the sitemap and llms.txt thrown in. Adding a tool is one registry entry, one engine function and tests. The pages write themselves, which is the only kind of page I enjoy writing.

Hosting. Cloudflare Pages. It serves files and answers GET requests. That's its entire personality.

Your browser. A small script handles the boring parts: picking files, options, progress, download. It has no idea what a PDF is. When you press the button, it borrows a specialist:

"Just use a server, bro"

I know. A server would have been easier. I chose pain for three reasons.

You can check it. "We delete your files" is a promise. This is a rule your browser enforces:

default-src 'self';
script-src 'self' 'wasm-unsafe-eval';
connect-src 'self';
img-src 'self' data: blob:;
object-src 'none'; base-uri 'none'; form-action 'none'

connect-src 'self' means the page can only talk to fizzdoc.com, and fizzdoc.com only serves the website. Open DevTools, go to Network, run a job, and watch nothing interesting happen. The test suite does the same thing on every pull request and fails if a single request goes anywhere else.

It's free to run. A file-processing server gets more expensive with every user. A static site doesn't care how popular it gets. That's the only reason I can say "free" without a pricing page hiding behind it.

No waiting in line. No upload bar, no "processing on our servers", no download. Your file goes from your disk to your RAM and back.

The catch is obvious: your device does the work, and not everyone has a laptop. Which brings us back to my six-minute disaster.

The Android bug

qpdf runs on Emscripten, which gives it a small pretend file system. I was handing it your file through WORKERFS, which reads the file lazily, only when qpdf asks for a piece. Sounds efficient, very "don't load what you don't need", and I was proud of it.

What I didn't know: qpdf doesn't ask for a few big pieces. It asks for lots and lots of tiny ones. On a 10 MB, 28-page test PDF, I counted 1,448 separate reads: 434 just to count the pages, and 1,014 more for the split.

On a laptop, 1,448 small reads is nothing. On Android, reading a picked file in small pieces is slow, and 1,448 slow things in a row add up to minutes. My "efficient" design was death by a thousand paper cuts (literally, since it was a PDF).

The fix was almost embarrassing:

// qpdf reads its input in thousands of small pieces, and on Android every small read
// of a picked file is slow. Only inputs too big to copy safely are still read lazily.
const COPY_UP_TO = 128 * 1024 * 1024;

if (totalSize <= COPY_UP_TO) await copyIn(q, files, run); // read once, in order, into memory
else q.FS.mount(q.WORKERFS, { blobs }, '/in');            // huge files: no second copy

If your files add up to 128 MB or less, the worker reads them once, start to finish, into memory. All those tiny reads now hit RAM, which doesn't care. Same test file: 1,448 reads became zero, and even on my laptop the split went from 1.4 s to 0.25 s. So the bug was slowing everyone down; phones were just louder about it.

Above 128 MB, making a second full copy could run a phone out of memory, so big files still get the lazy path. Slower, but it finishes. I tested that with a 140 MB PDF, and yes, I waited.

Being nice to a ₹8,000 phone

That bug taught me to design for the cheapest phone first, not my laptop. This is what changed because of it.

Load almost nothing

The first page load is about 15 KB of gzipped JavaScript and 7 KB of CSS. No framework. Every page is prerendered HTML, so you can read it before any script runs (Google can too).

The Inter font is split into 7 unicode-range pieces with font-display: swap, so your browser only downloads the characters a page actually uses, and shows text in a system font while it waits. A tiny theme.js sets dark mode before the first paint, so no white flash at 2 a.m. Hashed files are cached for a year, so the second visit is mostly just HTML.

Load engines only when asked

Each tool's engine hides behind a dynamic import():

'compress-pdf': async (f, o) => (await import('./engine/compress')).compressPdf(f[0], { ... }),
'ocr-pdf':      async (f) => (await import('./engine/ocr')).ocrPdf(f[0], progressLabel),

If all you do is rotate a PDF, you never download the OCR engine or a 58 MB speech model. Mermaid is even pickier: every diagram type is its own chunk, so drawing a flowchart doesn't drag in the code for sequence diagrams.

Check the budget before you spend it

Before a job starts, the page does a quick sanity check:

// 128 MiB per GiB of reported device memory, capped at 1 GiB.
function inputBudget() {
  const gib = navigator.deviceMemory;
  return gib ? Math.min(gib * 128, 1024) * MiB : 512 * MiB;
}

A 4 GB phone gets 512 MiB, an 8 GB laptop gets 1 GiB. Firefox and Safari don't report device memory, so they get a sensible 512 MiB. The cap exists because qpdf's WebAssembly memory tops out at 2 GiB and a job needs room for more than its input.

Is it a perfect measurement? No, and the code comment admits that. But "this file is too big for this device" is a much better message than a tab that quietly dies after five minutes.

Show real progress

A spinner on a slow phone is basically a "maybe" button. So the progress bar is real.

The first 30% is the file being read into memory, byte by byte. The other 70% comes from qpdf itself. qpdf has a --progress flag that prints lines like write progress: 42%. This WebAssembly build ignores the option meant to catch that output, so it just goes to console.log. Okay then, I'll grab it from there:

console.log = (...args) => {
  const pct = /: write progress: (\d+)%$/.exec(String(args[0]))?.[1];
  if (pct === undefined) return log(...args);
  post({ type: 'progress', fraction: READ_SHARE + ((1 - READ_SHARE) * Number(pct)) / 100 });
};

Is hijacking console.log elegant? Absolutely not. Does the bar move now? It does. I sleep fine.

One job, one worker, then gone

Every qpdf job gets its own fresh Web Worker, so the page stays smooth while it works. When the job ends, or you hit Cancel, the page calls worker.terminate(). That one line throws away the file, any password you typed, and the engine's whole memory, so the cancel button doubles as cleanup and leak prevention. No state survives between jobs, so memory doesn't slowly creep up while you merge your way through tax season.

Before running, the worker also asks qpdf what's in the file: bookmarks, forms, signatures, encryption. If you merge a signed PDF, Fizzdoc tells you the signature won't be valid anymore, instead of letting you find out from your CA.

Only draw what's on screen

The editor and the redaction tool show every page of your PDF. On a 200-page file that could mean 200 canvases fighting for memory. Instead, a page is drawn only when it's about to scroll into view:

const io = new IntersectionObserver(
  (entries) => { for (const e of entries) if (e.isIntersecting) renderPage(pages[e.target.dataset.index]); },
  { root: scroller, rootMargin: '600px 0px' },
);

Tools that must touch every page (PDF to JPG, scanned PDF, OCR) go one page at a time and clean each page up before moving on.

Do less work

• MP3 and M4A are cut without re-encoding. An MP3 is a row of little frames, each saying how long it is. Cutting is just picking the frames between two timestamps. No decoding, no quality loss, and fast even on a phone.
• Compression never makes things bigger. Each image inside a PDF is kept only if the new version is smaller. If the whole file doesn't shrink, you get your original back, not a "compressed" file that's 3% larger. (We've all seen that one.)
• "Compress image to 50 KB" is smart about it. It keeps the photo large and lowers quality first, never below 50% while it's 1000 px or wider, using a 6-step binary search. Only if that can't fit does it shrink the size. Roughly how messaging apps do it.

And when it's slow anyway, say so

While a job runs, the page tells you speed depends on your device. If something takes over 20 seconds or fails, a "Slow or not working? Report it on GitHub" link lights up. It opens a ready-made issue with the tool, browser, time taken, file size, and the device's RAM and CPU cores. Never the file, never its name. That link is how I find the next bug instead of guessing.

What's still not great: PDF to JPG keeps every page image in memory until the ZIP is built (a 1,000-page PDF on a phone would be a bad day), some jobs still run on the main thread, and Whisper runs on a single thread. Speaking of which.

Speech to text, without a server

This was the feature I wasn't sure a static site could pull off.

Fizzdoc runs Whisper tiny (8-bit quantized) with transformers.js and ONNX Runtime, on the CPU, inside a worker. It took three fights to get there.

Cloudflare Pages allows 25 MiB per file. The model is bigger. So a build script chops the model into parts. The first time you use the tool, the browser downloads the parts, glues them back together and keeps them in Cache Storage. After that it starts in seconds, even offline.

My own security rules blocked it. ONNX Runtime likes to load its WebAssembly through a blob: URL, which my CSP refuses. So the worker reads the file from the cache itself and hands it over directly. Remote model loading is switched off too, so it can only read from fizzdoc.com.

Nobody trusts a spinner for 58 MB. The first run says "Preparing… one-time setup: 23 of 58 MB" with a real byte counter, and tells you it only happens once.

Audio is turned into 16 kHz mono (what Whisper expects) and fed in 30-second windows with 5 seconds of overlap, so words at the edges don't get chopped in half.

Whisper tiny is, well, tiny. Clear English comes out well. Hinglish, sadly, does not. Give it Hindi and English in the same sentence and it answers with great confidence and very little accuracy. The tool now says it works best on clear English. Multi-threading would help speed, but it needs cross-origin isolation, and my first attempt made the worker hang. So it's single-threaded for now. If you've solved this, please come find me.

Smaller decisions I'd defend in a code review

Redaction that actually redacts. Drawing a black box over text doesn't remove it. People still do that, and people still copy the text out from under the box. Fizzdoc turns each page into an image with the boxes burned in, then builds a new PDF from those images. The text is really gone. The trade-off is the result isn't selectable text, and the tool says so. There's also an optional "find personal info" button that marks emails, UPI IDs, phone numbers, PAN, IFSC, IBAN and long ID numbers. It's plain regex, not AI, and you check every mark before saving.

Editing text in place, in the PDF's own font. Click a line in a PDF and retype it. On save, Fizzdoc parses the page's content stream, tracks the text state (matrices, font, spacing) to find the exact operators that draw that line, and rewrites them using the font that's already embedded in the file. Same font, same size, same colour, no white box. The catch: embedded fonts are usually subsets, so you can only use letters the file already contains. Change "Rs 4,250" to "Rs 2,450"? Easy. Type a "Z" into a PDF that never had one? The glyph simply isn't there, so that line falls back to covering the old text and drawing new text in the closest standard font. Hindi and Arabic always take the fallback too, because their glyphs are drawn in a different order than they're typed, and I'd rather be boring than garbled.

Word to PDF via the print dialog. Drawing Hindi, Tamil or Arabic correctly inside a JavaScript PDF writer is a whole career. Every browser already ships a great PDF writer: Print → Save as PDF. So Fizzdoc turns your .docx into clean HTML and opens the print dialog. One extra click, and every script comes out right. Lazy, yes, but it works.

qpdf instead of a JavaScript PDF library. I started with pdf-lib for merging. It works, but copying pages that way drops bookmarks, form fields and internal links. qpdf rewrites the file's structure instead, and has been doing it reliably for years.

Bonus: your coding agent can use it too

Hacktoberfest is big on agents this year, so here's a small one. The repo has an MCP server (in /mcp) that runs the same qpdf and audio engines locally. Hook it up to Claude Code, Codex or Cursor and you can say "merge these PDFs" or "cut the first 30 seconds of this MP3", and the agent does it on your machine. No upload, no throwaway Python script, and it never overwrites your files.

Lots of languages, one source file

Each language has real URLs (/hi/merge-pdf/, /ta/compress-pdf/), translated buttons, FAQs and error messages, and hreflang links between them: Hindi, Bengali, Marathi, Tamil, Telugu, Spanish, Portuguese, French, German, Italian, Dutch, Polish, Turkish, Indonesian, Vietnamese and English.

Because every page is generated, the tests can check all ~1,050 of them for their CSP, title, description, canonical link, a single h1 and valid structured data. I'm not checking 1,050 pages by hand.

Tests, because I like sleeping

209 unit tests and 1,087 browser tests. Engines are plain functions (bytes in, bytes out), so most run in Node against small weird files: encrypted PDFs, forms, bookmarks, MP3s. The browser tests click through the real UI, including the "no request leaves the site" check. CI runs both on every pull request, and nothing merges red.

Come build it with me

Right now Fizzdoc is one person and a lot of tabs. There's plenty left, and some of it is really fun engineering. Hacktoberfest doesn't count pull requests anymore, which honestly suits me. I'd much rather have one good PR that someone understands than ten that just exist.

Good first issues

• Crop PDF, Flatten PDF, Split every N pages
• Pick the DPI for PDF → JPG, watermark position and colour
• Word → Markdown / HTML
• Translations: Japanese, Korean, Gujarati, Kannada, Malayalam, Punjabi

Bigger ones

• Sign PDF
• OCR in more languages, downloaded on demand like Whisper
• Install it as an offline app (PWA)
• Page thumbnails with drag and drop
• WAV, FLAC, OGG and OPUS in the audio tools
• Remove image background, on the device
• Right-to-left languages

Problems I'd love your brain on

• Faster Whisper: threads (COOP/COEP without the hang) or WebGPU. If you've shipped either, tell me everything.
• A bigger or multilingual open-weight speech model that still fits a phone, so Hinglish stops being a comedy show.
• More MCP tools: the image, OCR, redaction and Office engines in Node.
• Streaming the ZIP for PDF to JPG, so huge PDFs don't sit in memory.
• Real text deletion in Edit PDF, rewriting the content stream instead of covering it.

Setup takes about as long as reading this sentence twice:

git clone https://github.com/kingrishabdugar/fizzdoc
cd fizzdoc
npm install
npm run dev

CONTRIBUTING.md shows how a tool goes from the registry to its engine. Small pull requests get reviewed fastest. Not sure where to start? Comment on any issue and I'll help you pick one.

https://github.com/kingrishabdugar/fizzdoc

That's it

Try it at fizzdoc.com. Throw your weirdest PDF at it. If it's slow on your phone, hit the report link and tell me which phone, so I can have another humbling morning.

And if you think it's useful, a star on kingrishabdugar/fizzdoc helps more people find it. It also makes me unreasonably happy.

Thanks for reading.