DEV Community: WebsiteGeek

Building a PDF Toolkit That Never Touches a Server

WebsiteGeek — Thu, 27 Aug 2026 02:47:32 +0000

Every PDF tool follows the same pattern: upload your file, wait, download the result. That server round-trip exists because PDF processing is genuinely expensive — parsing a file format never designed to be edited, re-encoding pages, running compression. Doing that in a browser tab used to mean either a thin wrapper around a server API, or nothing at all.

That's changed. WebAssembly-compiled versions of real PDF libraries are fast enough now to run entirely client-side, and building DeskRamp meant figuring out what that actually takes inside a Chrome extension, not just a regular web page.

The CSP wall

Manifest V3 extensions get a strict default Content Security Policy, and WebAssembly needs an explicit exception to run at all:

"content_security_policy": {
"extension_pages": "script-src 'self' 'wasm-unsafe-eval'; object-src 'self';"
}

Without 'wasm-unsafe-eval' explicitly declared, WebAssembly.instantiate() throws immediately — Chrome treats compiled WASM the same security-sensitive way it treats eval(), since both execute code the browser can't statically analyze ahead of time. This is a one-line fix once you know it's needed, but it's the first thing that breaks silently if you're porting WASM-based processing into an extension for the first time.

Picking a library per task, not one library for everything

No single library covers merge, split, compress, convert, and e-Sign well. DeskRamp bundles a few, each doing the one thing it's actually good at:

pdf.js — rendering and reading PDF structure
pdf-lib — merging, splitting, and building new PDF documents
qpdf (compiled to WASM) — the actual compression and password/decryption work, which needs low-level access to PDF's internal object structure that higher-level libraries don't expose
docx / pptxgen / xlsx libraries — format conversion into and out of Office formats

This means the extension ships several hundred KB to a few MB of vendored library code, which matters for install size and initial load time. The practical fix is lazy-loading: nothing pulls in qpdf's WASM binary until the user actually clicks "Compress," rather than loading every processing library up front for a toolkit most of a session won't touch.

The real ceiling: browser tab memory, not CPU

The unexpected constraint wasn't processing speed — modern WASM PDF processing is fast enough that a merge or split feels instant on anything but a huge file. It's memory. A browser tab has a much lower practical memory ceiling than a server process does, and a large multi-hundred-page PDF fully parsed into memory, plus the WASM runtime's own working memory, plus whatever else the tab is holding, can hit that ceiling in a way a server-side version of the same operation never would.

The mitigation is processing in chunks where the library supports it (streaming page-by-page rather than materializing the whole document object graph at once) and being explicit about releasing references (ArrayBuffers, typed arrays) as soon as a stage finishes, rather than trusting garbage collection to catch up on its own timeline while a multi-step operation is still running.

Why this is worth the extra complexity

The upload step in a typical PDF tool isn't just slower — it's the whole reason people hesitate to use these tools for anything they'd actually rather not hand to a server: contracts, IDs, financial documents. Once WASM-based processing is fast enough to feel native, there's no real reason left to default to a server round-trip for tasks like merge, split, compress, and convert. The extra engineering constraints (CSP, bundle size, memory ceilings) are the actual cost of that tradeoff — worth paying once, not something that needs solving per-feature.

If you're curious what this looks like shipped: DeskRamp is free on the Chrome Web Store.

Why I Stopped Trying to Block Facebook Entirely

WebsiteGeek — Wed, 26 Aug 2026 02:30:51 +0000

I've tried almost every site blocker that exists. StayFocusd, Cold Turkey, Freedom, BlockSite — I've installed and uninstalled all of them at some point over the years, usually within a week of a New Year's resolution to "focus more." They all work the same way: you give them a list of sites, and they block those sites. Simple, effective, and completely wrong for how I actually use the internet.

Here's the problem nobody talks about: the sites I need to block aren't sites I never need. Facebook has a Marketplace listing I'm mid-conversation on. Instagram has a client's DM I'm waiting on. X has a thread I actually need to reference for work. Blocking the whole domain doesn't just remove the distraction — it removes the one legitimate reason I had the tab open in the first place.

So I'd disable the blocker "just for five minutes," and you already know how that story ends.

The distraction isn't the site. It's the feed.

At some point I realized the thing pulling me back in was never the platform — it was always the feed. The infinite, algorithmically-tuned scroll that exists specifically to keep me there past the point I intended. The Marketplace listing, the DM, the work thread — none of that is what hijacks twenty minutes of my afternoon. The feed is.

That reframing changed what I was actually trying to build. Not a better block list. A tool that understands the difference between a site and the specific part of that site engineered to be addictive.

What I ended up building

FocusRamp is a Chrome extension that hides distracting feeds — Facebook's, Instagram's, X's — instead of blocking the whole site. Open Facebook and the news feed simply isn't there, but Marketplace, Groups, and Messenger still work exactly as they always have. You keep what you need. You lose what you don't.

On top of that, it does the things I actually wanted from a blocker in the first place:

Site blocking for the genuinely useless stuff — the sites where there's no "but I need this part" exception, so a full block makes sense.
A real Pomodoro timer, because focus mode without a session structure is just a passive setting I forget is even on.
Scheduled focus mode, so it turns itself on during work hours instead of relying on me to remember every morning.
Why I made it free

I didn't want to build something I wouldn't trust installing myself, and a tool that asks for payment before you've even tried it is a tool I usually never install at all. So the core of FocusRamp — site blocking, feed hiding, the Pomodoro timer, scheduling — is free forever, no account required. There's a Pro version with some extra features, but it's a one-time purchase, not a subscription. I have enough subscriptions I've forgotten I'm paying for; I didn't want to add to anyone else's pile.

If you've been through the same cycle — install a blocker, disable it a week later, feel vaguely guilty, repeat — I built this for exactly that problem.

FocusRamp is free on the Chrome Web Store: chromewebstore.google.com/detail/focusramp-site-blocker

Or read more about it here: websitegeek.net/focusramp

I'd genuinely like to hear what's missing if you try it — this is still early, and the roadmap is shaped by what people actually hit friction on, not a feature list I decided on alone.

How to check your browser's privacy with 30 lines of JavaScript — and what I learned

WebsiteGeek — Wed, 08 Jul 2026 16:15:00 +0000

What most people don't know about their browser

Your browser leaks more than you think — and you don't need a third-party tool to check it. Most of the signals you need are already in the browser's native APIs.

The 6 checks I run (and the JS code)

1. HTTPS status
window.location.protocol === 'https:'

2. Cookies enabled
navigator.cookieEnabled

3. Local storage available
Try/catch a localStorage.setItem() call

4. Do Not Track signal
navigator.doNotTrack === '1'

5. Private/Incognito heuristic
Check localStorage quota — private mode caps it at ~5MB in most browsers

6. Browser detection
navigator.userAgent parsing for Chrome/Firefox/Safari/Edge

Turning it into a score

Each check that passes adds points to a score out of 100. I weight DNT and HTTPS more heavily because they have the most real-world impact.

What I built with this

A free browser privacy checker that runs these 6 checks instantly and gives you a score, a verdict, and a personalized list of things to fix.

👉 Browser Privacy & Security Checkup

What I want to add next

WebRTC leak detection (navigator.mediaDevices.enumerateDevices)
Canvas fingerprint score
Third-party cookie isolation check

What would you add? Have you built something similar?

I built a WiFi QR Code Generator that runs 100% in your browser

WebsiteGeek — Fri, 03 Jul 2026 16:20:00 +0000

The Problem

Sharing your WiFi password out loud is awkward. Typing it on a guest's phone takes forever. And some passwords are 20+ characters.

The WiFi QR Code Trick

A WiFi QR code encodes your network credentials in a format phones understand natively — iOS 11+ and Android 10+ both support it without any app. Guest scans it, connects instantly.

The QR string format looks like this:
WIFI:T:WPA;S:YourNetworkName;P:YourPassword;;

How I Built It (in 40 lines of JavaScript)

[paste 20–30 lines of your actual JS generator code here]

The key is using a QR library like qrcode.js and building the WIFI: string dynamically from the form inputs.

What I Added for Better UX

Show/hide password toggle
Network type dropdown (WPA2, WPA3, WEP, None)
Hidden network checkbox
One-click download as PNG

Real Use Cases

I designed this with 4 scenarios in mind:

House guests who can't connect
Airbnb hosts who change passwords monthly
Office WiFi for visitor access
New home setup — print it and stick it on the router

Try It Free

👉 WiFi QR Code Generator — no signup, nothing stored.

I also built a Password Generator and a Browser Privacy Checker as part of the same toolkit.