I Built a PDF Tool That Never Touches a Server - Here's the Architecture

​Most PDF tools online have the same dirty secret: your files get uploaded to

someone's server, processed, and (hopefully) deleted. I wanted to build

something different - a suite of PDF tools that processes everything entirely

in the browser, with zero server contact.

The result is ZeroCloudPDF (https://zerocloudpdf.com) - 13 browser-based PDF

tools including merge, compress, image-to-PDF, HEIC-to-PDF, Word-to-PDF,

PDF-to-JPG, and more. Here's how I built it and what I learned.

THE CORE PRINCIPLE: BROWSER AS THE BACKEND

All heavy lifting happens client-side using three libraries:

- jsPDF - for generating PDFs from images and Word docs

- PDF.js - for rendering and extracting PDF pages

- Mammoth.js - for parsing .docx files

No Node.js runtime on the server. No Lambda. No file storage.

The file never leaves the tab.

THE BUILD SYSTEM: ONE TEMPLATE, 13 PAGES

The site is hosted on Firebase. Rather than maintaining 13 separate HTML files

manually, I built a small Node.js script - generate-pages.js - that takes a

single template.html and stamps out all 13 pages.

Across all pages, only 7 tags differ:

- title

- meta description

- canonical

- og:title

- og:description

- og:url

- 5 hreflang hrefs

Everything else - the upload UI, tool tabs, privacy section, FAQ schema, blog

cards - is shared. The deploy workflow is just:

node generate-pages.js

firebase deploy

This keeps the codebase lean and makes SEO updates trivially easy - change the

template once, regenerate all pages.

THE SEO TRAP I FELL INTO

Early on, I used a Firebase wildcard rewrite:

  { "source": "**", "rewrites": [{ "function": "..." }] }

This caused Google Search Console to flag several pages as "Alternative page

with proper canonical tag" - meaning Google had cached the wildcard behavior

and was confused about which URL was canonical, even after I added explicit

HTML files.

The fix wasn't a code change - it was patience plus submitting the sitemap and

requesting re-indexing via Search Console. The wildcard rewrite was telling

Google "all these URLs are the same thing," which undercut the individual

canonicals.

Lesson: On Firebase, if you're building a multi-page static site for SEO,

skip wildcard rewrites entirely and serve individual HTML files.

PRIVACY AS A FEATURE, NOT A FOOTNOTE

Since no files hit the server, I could make strong privacy guarantees:

- No file upload, ever

- No AI training on your documents

- No metadata harvested (EXIF, GPS, timestamps)

- No activity logging

- Tab closed = all traces gone