DEV Community: Shahzaib

5 PDF Tools Nobody Else Gives You for Free (All Running 100% in Your Browser)

Shahzaib — Fri, 09 Oct 2026 18:22:36 +0000

Series: Building PdfWord — a free, no-backend PDF tools site (Part 6)

Most free PDF sites give you the same 10 tools: merge, split, compress, convert. I have those too. But this week I shipped 5 tools I couldn't find on any free PDF site — all running entirely in the browser, no uploads, no accounts.

Here's what they are and how they work.

1. Visual PDF Compare — differences glow red

Upload two PDFs (original + revised). Every page pair is rendered and pixel-compared; differences glow red, identical content fades. You get a similarity score per page plus a downloadable diff report.

The trick: render both pages to canvas with pdf.js at the same scale, walk the pixels, flag any with channel difference > 32 (ignores anti-aliasing noise), and paint a diff visualization. ~40 lines of JS. Adobe charges for this; mine's free.

2. Listen to PDF — your documents read aloud

Upload a PDF, and the browser's built-in speech synthesis reads it to you — with voice picker and speed control. Zero libraries, zero cost: it's just speechSynthesis + pdf.js text extraction, chunked at sentence boundaries so pause/resume works naturally.

3. Split by Size — beat Gmail's 25MB limit

Nobody does this: pick a max part size (10/25/50/100 MB) and the tool splits your PDF into chunks guaranteed under the limit. It adds pages one by one with pdf-lib and byte-measures every part — no estimation, no overshoot.

4. Grayscale PDF — save your color ink

One click turns every page black & white for cheap printing. Rendered via canvas grayscale(1) filter, re-embedded at high resolution.

5. Scanned PDF to Word (OCR) — the hard one

This took real work: Tesseract.js running in the browser via WebAssembly. Scanned pages are rendered to images, OCR'd page by page, and assembled into an editable .docx.

The gotcha that cost me 3 failed QA runs: Tesseract.js v5 requests eng.traineddata.gz by default — a file that doesn't exist unless you create it. The fix was embarrassingly simple: ship both eng.traineddata and the .gz version. The worker gunzips transparently.

And the privacy angle no other free OCR site can claim: your scans never leave your device. Every other free OCR uploads your documents to their servers. Mine can't — there is no server.

The pattern

Every one of these follows the same playbook: find a task people assume needs a backend, then prove it doesn't. pdf.js renders, pdf-lib edits, Tesseract reads, speechSynthesis speaks, JSZip bundles.

Try them: PdfWord — 34 free tools, no signup, no watermark.

What impossible-in-browser tool should I build next?

I Made My Web App Receive Files From WhatsApp — No Backend, Just Web APIs

Shahzaib — Fri, 09 Oct 2026 16:43:48 +0000

Series: Building PdfWord — a free, no-backend PDF tools site (Part 5)

My PDF tools site is a PWA — installable, works offline. But last night I asked myself: am I actually using the "app" part, or is it just a bookmark with a nice icon?

So I upgraded it with three real platform integrations. All client-side. Zero backend. Here's how.

1. Share Target: receive PDFs from WhatsApp

This is the big one. On Android, when you share a PDF from WhatsApp, Gmail, or Files, PdfWord now appears in the share sheet — and the file opens pre-loaded in the app.

It takes two pieces:

The manifest declares what you accept:

"share_target": {
  "action": "/share.html",
  "method": "POST",
  "enctype": "multipart/form-data",
  "params": {
    "files": [{ "name": "pdfs", "accept": ["application/pdf", ".pdf"] }]
  }
}

The service worker intercepts the POST (a static host can't parse multipart forms, but the SW can):

self.addEventListener('fetch', e => {
  const url = new URL(e.request.url);
  if (e.request.method === 'POST' && url.pathname === '/share.html') {
    e.respondWith((async () => {
      const fd = await e.request.formData();
      const files = fd.getAll('pdfs').filter(f => f && f.size > 0);
      if (files.length) {
        const cache = await caches.open('pdfword-shared-v1');
        await cache.put('shared-0', new Response(files[0], {
          headers: { 'X-Filename': encodeURIComponent(files[0].name) }
        }));
      }
      return Response.redirect('/share.html?shared=1', 303);
    })());
  }
});

Then share.html reads the file from the cache, shows it, and offers tool buttons (Compress, Merge, PDF to Word…). Clicking one stashes the file in IndexedDB and navigates to the tool page, where a small script in my shared common.js injects it into the file input via DataTransfer — so the tool's existing upload handler just works, no per-tool changes needed.

The whole flow feels native. The user never picks a file twice.

2. App shortcuts: long-press the icon

Three quick actions in the manifest — Merge PDF, Compress PDF, PDF to Word:

"shortcuts": [
  { "name": "Merge PDF", "url": "/merge-pdf.html",
    "icons": [{ "src": "assets/icons/icon-192.png", "sizes": "192x192" }] },
  ...
]

Long-press the installed app icon and jump straight to the tool. Five minutes of work, genuinely useful.

3. iOS install hint (because Apple won't give us the prompt)

iOS Safari doesn't fire beforeinstallprompt, so my install button did nothing there. Now iOS users get the button too — tapping it shows: "Tap Share ⬆️ then 'Add to Home Screen' to install PdfWord." Small, honest, better than a dead button.

The lesson

A PWA isn't an "install button." It's the moment your web app starts behaving like it belongs on the device — receiving shares, offering shortcuts, working offline. Every one of these is a web standard, no app store, no review process, no backend.

Try it: install PdfWord on Android, share any PDF from WhatsApp to it, and watch it open ready to compress. That's the demo I'm proudest of.

What platform API should I wire up next? File Handling? Protocol handlers? Tell me in the comments.

How I Shipped 2 New Features Without a Backend: PDF to PNG + Flatten PDF

Shahzaib — Fri, 09 Oct 2026 16:11:13 +0000

Series: Building PdfWord — a free, no-backend PDF tools site (Part 4)

Last week I cut my homepage from 4.8MB to ~70KB and made my PWA open instantly (Part 2). This week I shipped two brand-new tools — taking the site from 27 to 29 free tools — still with zero backend, zero database, and zero server bills.

The tools: PDF to PNG (lossless page images) and Flatten PDF (lock form fields permanently).

Here's exactly how they work in the browser.

1. PDF to PNG: pdf.js + canvas + JSZip

The trick is the same one I used for PDF to JPG: render each page to a <canvas> with pdf.js, then canvas.toBlob() — but with the image/png MIME type instead of image/jpeg:

const page = await pdf.getPage(i);
const viewport = page.getViewport({ scale: 2 }); // 2x for crisp text
const canvas = document.createElement('canvas');
canvas.width = viewport.width; canvas.height = viewport.height;
await page.render({ canvasContext: canvas.getContext('2d'), viewport }).promise;
const blob = await new Promise(res => canvas.toBlob(res, 'image/png'));
zip.file(name + '-page-' + i + '.png', blob);

Everything runs on the main thread (canvas needs the DOM), with a progress bar per page and page.cleanup() to free memory between pages — important for 100+ page PDFs on phones.

Why PNG and not just JPG? PNG is lossless. For text documents, screenshots, and graphics, JPG's compression artifacts make text fuzzy. Users kept asking — so now they have both.

2. Flatten PDF: pdf-lib's `form.flatten()`

This one's a one-liner with pdf-lib:

const { PDFDocument } = window.PDFLib;
const pdf = await PDFDocument.load(buffer);
try {
  const form = pdf.getForm();
  form.flatten(); // burns every field into the page
} catch (e) { /* no form fields — still saves a clean copy */ }
const out = await pdf.save();

Flattening is the thing lawyers and HR departments do before emailing contracts: the filled values stay visible but can never be edited or cleared. Before this, my users had to print-to-PDF and lose quality. Now it's one click, in the browser.

The whole tool is ~25 lines of JS. The page, SEO copy, and FAQ took longer than the code.

The playbook so far (all free, all client-side)

Ship real tools that solve one problem well
Give every tool its own page: SEO title, how-to steps, FAQ with JSON-LD schema
Add it to the homepage grid + sitemap, ping IndexNow
Write about it here on dev.to — the articles are my #1 traffic source after directories

Try them: PDF to PNG · Flatten PDF — no signup, no watermark, files never leave your browser.

What tool should I build next? Drop a comment — I read every one.

How to Fill PDF Forms in the Browser with pdf-lib (No Server Needed)

Shahzaib — Fri, 09 Oct 2026 11:23:35 +0000

I recently added a "Fill PDF Form" tool to my free PDF toolkit PdfWord. Everything runs client-side — the PDF never leaves the user's device. Here's how it works, in case you want to build something similar.

Reading form fields

pdf-lib exposes AcroForm fields directly:

import { PDFDocument } from 'pdf-lib';

const pdfDoc = await PDFDocument.load(arrayBuffer);
const form = pdfDoc.getForm();
const fields = form.getFields();

fields.forEach(f => {
  console.log(f.getName(), f.constructor.name);
  // PDFTextField, PDFCheckBox, PDFDropdown, PDFRadioGroup, PDFButton
});

Filling them

const textField = form.getTextField('full_name');
textField.setText('Shahzaib');

const checkBox = form.getCheckBox('agree');
checkBox.check();

const dropdown = form.getDropdown('country');
dropdown.select('Pakistan');

The minification gotcha

In production builds, field.constructor.name becomes something like e or t — minifiers rename classes. My first version used constructor.name checks and silently failed on the live site while working in dev.

Fix: use instanceof checks against the pdf-lib classes instead:

import { PDFTextField, PDFCheckBox, PDFDropdown, PDFRadioGroup } from 'pdf-lib';

if (field instanceof PDFTextField) { /* ... */ }
else if (field instanceof PDFCheckBox) { /* ... */ }
// ... etc

instanceof survives minification. constructor.name doesn't. This one burned me in production — test your built bundle, not just dev.

Flattening (optional)

If you want the filled values burned into the page so they can't be edited:

form.flatten();
const bytes = await pdfDoc.save();

Updating appearances

One more gotcha: after setting values programmatically, call form.updateFieldAppearances() (or the default font embedding pdf-lib does) so the filled text actually renders in viewers. Without it, some PDF readers show blank fields despite the values being set.

Why client-side?

For a privacy-sensitive feature like form filling (think job applications, tax forms, medical paperwork), "your file never leaves your device" isn't just a technical detail — it's the whole selling point. pdf-lib makes it genuinely feasible: parse, fill, flatten, download, all in the browser.

PdfWord is a free, no-signup PDF toolkit — 27 tools, installable as a PWA, works offline. The fill-form tool and this writeup both came out of building it.

How I Cut My Homepage from 4.8MB to 70KB (and Made My PWA Open Instantly)

Shahzaib — Fri, 09 Oct 2026 10:50:39 +0000

My free PDF tools site PdfWord had a problem: the installed PWA took forever to open on phones. Users complained. Here's the 20-minute fix that cut 98.5% of the weight.

The diagnosis

I measured what the homepage actually downloads:

Library	Size
html2pdf.bundle.min.js	884 KB
xlsx.full.min.js	861 KB
docx.min.js	725 KB
pdf-lib.min.js	512 KB
pptxgen.bundle.js	466 KB
jspdf.umd.min.js	410 KB
pdf.min.js	312 KB
…plus 25 more scripts	…

Total: 4.8 MB of JavaScript — on a landing page.

The homepage is just cards that link to tool pages. It needed none of these. Every library was loaded "just in case," plus 22 dead inline tool panels from an older design.

The fix

Deleted the 22 dead tool panels from the homepage (dedicated tool pages already existed — 25 KB of dead HTML gone).
Removed all 33 heavy <script> tags from the homepage. Each tool page still loads only the libraries it needs (selective per-page loading).
Kept one file: common.js (15 KB) for navigation, theme toggle, and filters.

Result: 54 KB HTML + 15 KB JS = ~70 KB total. Down from 4.8 MB.

The service worker lesson

I also found the service worker was precaching ~2 MB of libraries on install. Trimmed the precache to the app shell only (~120 KB); heavy libs now cache on-demand when their tool page is first opened. And HTML uses a network-first strategy so updates reach installed apps without reinstalls.

Rule I now follow: bump the SW cache version on every deploy, or installed apps serve stale files forever.

Results

Page load: 422 ms (Cloudflare Web Analytics, real devices)
Core Web Vitals: 100% Good across LCP, INP, CLS
PWA opens instantly on 4G

The takeaway: audit what your landing page actually needs. "Just in case" script tags are the silent killer of mobile performance.

PdfWord is a free, no-signup, client-side PDF toolkit — 27 tools, installable as a PWA, works offline. Built with vanilla JS and pdf-lib.

I built a free iLovePDF alternative with zero backend

Shahzaib — Thu, 08 Oct 2026 14:58:29 +0000

I kept hitting "free limit reached" on PDF tools while job hunting, so I built my own: PdfWord — 22 PDF tools, 100% free, no signup, no watermarks.

The interesting part: there is no backend. Everything runs client-side:

pdf-lib for merge/split/compress/rotate/watermark — runs in a Web Worker so the UI never freezes
pdf.js for rendering and text extraction
Zero server, zero database, zero tracking — files never leave your device

This architecture has a beautiful side effect: no server costs means it can genuinely stay free forever. Most "free" PDF sites need paywalls because they pay for server processing per file. No servers → no per-file cost → no limits.

Performance lesson: my first version loaded every JS library on every page — 4.6MB, 4.1s load on 4G. I switched to selective per-page loading (each tool page only loads what it needs). Now pages are 40–500KB loading in ~0.9s. Same tools, 100x lighter.

SEO lesson: I gave every tool its own page (/merge-pdf, /compress-pdf...) instead of one SPA — 22 indexable pages plus 8 how-to guides, all static.

Honest limitations: no OCR, no password unlock, no PDF/A — those need server-side processing or heavy models. I left them out rather than faking them.

Stack: static HTML + vanilla JS, hosted on Cloudflare Pages (free). Total hosting cost: $0.

It's my first launched project (I'm actually an electrical engineer, not a web dev). Roast it — what's missing?