DEV Community: Jeffrey Hamilton

I built a PDF merger that never uploads your files — here's how published: false

Jeffrey Hamilton — Tue, 18 Aug 2026 13:00:00 +0000

MergePDF is a 100% client-side PDF tool. No backend, no uploads, no sign-up. Here's the architecture, the tricky parts, and why privacy is a feature, not a setting.
Every tax season, the same thing happens. Someone in my family asks me to merge a few PDFs. They Google "merge PDF." They click the first result — a slick, friendly-looking site. They upload their tax returns to a server they've never heard of.

That bothered me.

So I built MergePDF. It merges, splits, rotates, and rearranges PDF pages — and your files never leave your browser. No backend. No sign-up. No ads. No tracking.

iLovePDF uploads your tax returns. We don't.

This post is about how it works, the parts that were harder than I expected, and why "client-side only" is a design philosophy, not just a technical choice.

The pitch in 30 seconds
Drop one or more PDFs onto the page. You get a grid of page thumbnails — real, rendered previews of every page. Drag to reorder. Click to select. Rotate, delete, extract a range. Merge everything into one file, or split into single-page PDFs zipped up. Download. Done.

Your browser does all of it. There is no server processing documents. There isn't even a server to process documents.

The stack
It's a Next.js app, but honestly Next.js is just the host here. The interesting parts are all client-side libraries doing real work:

No database. No API routes. No auth. No analytics. The only thing in localStorage is your theme preference.

Drag-to-reorder that doesn't fight tap-to-select
This one took three attempts. The requirement:

Tap a thumbnail → select it (emerald ring)
Shift-tap → select a range
Long-press + drag → reorder
Swipe on mobile → scroll the grid (don't drag)
The conflict: if the whole card is the drag handle, taps get swallowed. If only a tiny grip icon is the handle, nobody finds it (especially on mobile, where there's no hover).

So split produces a ZIP. fflate's zip packages every single-page PDF into one download. Rotations are honored here too — each split page keeps its rotation via setRotation.

What I deliberately left out
No accounts. Nothing to phish, nothing to leak, nothing to manage.
No analytics. I don't know how many people use it, and I'm fine with that.
No paid tier. No watermarks on free output, no "upgrade to merge more than 5 pages."
No "AI features." I considered adding "summarize this PDF" and decided no. It would require either a server (defeats the purpose) or running a model in the browser (heavy, and most users don't want it). The tool does one thing well.
Limits, honestly stated
Client-side has real constraints:

Memory. A 500-page PDF will strain a mobile browser. I cap at 50 pages on mobile, 200 on desktop, and warn instead of silently truncating.
Encrypted PDFs. pdf-lib loads them with ignoreEncryption: true, but if they're actually password-protected, rendering fails gracefully (the thumbnail shows "Render failed" and the page is skipped, never a crash).
No OCR. If you need text extraction from scanned images, this isn't the tool. That's a server-or-model problem.
Try it
The code is on GitHub: https://github.com/JeffreyHamilton6399/MergePDF. It deploys to Vercel with zero environment variables — import the repo, click deploy, you're done.

If you build something with it, or find a bug, I'd love to hear about it. And if this is the kind of tool you'd rather use than the one that uploads your tax returns — well, that's the whole point.

If you found this useful, I write about client-side web stuff and don't have a newsletter to plug. I do have a Buy Me a Coffee if you're feeling generous.

I built a file transfer tool where the files never touch a server (WebRTC P2P)

Jeffrey Hamilton — Tue, 11 Aug 2026 14:00:00 +0000

Every time you need to move a file from your phone to your computer (or vice versa), your options are:

Email it (25MB limit, uploads to a server)
Google Drive (uploads to Google's servers, stored forever)
WeTransfer (uploads to their servers, 2GB limit)
AirDrop (Apple only)
None of these are great for privacy. Your files are sitting on someone else's server.

So I built FileBeam — it transfers files directly between two devices via WebRTC. No cloud, no uploads, no size limits.

Try it: filebeam-ten.vercel.app
Source: https://github.com/JeffreyHamilton6399/filebeam

How it works
text

Device A (Sender) Device B (Receiver)
│ │
│ ── WebRTC P2P ──────────│ (files go DIRECTLY, encrypted)
│ │
└── Signaling relay ──────┘
(6-digit code + handshake only)
(NEVER sees file data)
Device A: Drop files → get a 6-digit code + QR code
Device B: Enter the 6-digit code (or scan QR)
Files transfer directly from A to B via WebRTC data channels (end-to-end encrypted via DTLS)
The signaling server only passes the 6-digit code and connection handshake — it NEVER sees the files
The architecture
Frontend: Next.js 16 + Tailwind + shadcn/ui (hosted on Vercel)
Signaling: A tiny socket.io relay (~130 lines, hosted on Render's free tier)
Transfer: WebRTC RTCPeerConnection + data channels (16KB chunks)
Encryption: WebRTC DTLS (built into the protocol — files are encrypted in transit)
Key technical decisions

WebRTC data channels (not HTTP)

Files stream in 16KB chunks via RTCDataChannel. This allows true peer-to-peer transfer — the files go directly from device A to device B, never passing through any server.

A minimal signaling relay

A ~130-line socket.io server relays only the 6-digit code and WebRTC SDP/ICE candidates so the two devices can find each other. It never receives, stores, or sees file data, file names, or file sizes. The room is destroyed when the transfer ends or a device disconnects.

6-digit codes = 1 million possibilities

Brute force is impractical for ephemeral rooms that auto-destroy.

Stream large files

Files are read via file.stream().getReader() and sent in 16KB chunks — meaning even multi-GB files can transfer without loading into memory.

The privacy model (honest version)
Files go direct — file bytes, names, and sizes travel only over the encrypted peer-to-peer data channel. No server ever receives or stores them.
End-to-end encrypted — WebRTC DTLS encryption is built into the protocol.
No file storage anywhere — nothing is saved on any server, ever.
No accounts, no tracking, no analytics.
What the signaling server sees: the 6-digit code and connection info (IPs/ICE candidates) needed to pair the devices. That's inherent to WebRTC — two devices need to exchange connection info before they can connect directly. It never sees file data.
Open source — read every line of code.
Try it
Live: filebeam-ten.vercel.app
Source: https://github.com/JeffreyHamilton6399/filebeam

Email uploads your files. Google Drive stores them forever. FileBeam sends them directly.

FileBeam is built with Next.js 16, WebRTC, Tailwind CSS, and shadcn/ui. The signaling relay runs on Render's free tier.

I built a privacy-first face blurring tool that runs entirely in your browser

Jeffrey Hamilton — Tue, 11 Aug 2026 11:44:00 +0000

Every photo you share online might expose more than you intend — faces of your kids, strangers in the background, license plates, addresses on envelopes, watermarks with your name.

I wanted a tool that:

Blurs faces automatically
Detects text like license plates and watermarks
Never uploads my photos anywhere
Works on mobile
Is 100% free
Existing tools either upload to a server (no thanks) or require manual editing. So I built BlurIt — a fully client-side face and text blurring app.

How it works
Face detection uses SSD MobileNet V1 via TensorFlow.js — a multi-scale single-shot detector that catches small, distant, and partial faces even in crowd scenes. I implemented multi-scale quadrant detection (running the model on the full image + 4 overlapping zoomed quadrants) to catch background faces that single-pass detection misses.

Text detection uses Tesseract.js v7 with image preprocessing (2x upscaling + grayscale + contrast normalization) and multi-PSM detection (PSM 3 for structured text, PSM 1 for rotated/sideways text, PSM 11 for scattered text like watermarks).

Both models run locally in the browser via WebAssembly — your photos never leave your device. The model weights are self-hosted (same-origin), so there are zero third-party network requests for user data.

The privacy architecture
text

User drops photo
↓
Browser decodes (createImageBitmap)
↓
Canvas + ML model (local WASM)
↓
User taps to blur
↓
Canvas renders pixelate/gaussian/black
↓
Download — done
No server. No API. No database. No analytics. No tracking. The only things stored are your theme preference and a one-time terms acceptance in localStorage.

The UX
I took inspiration from iLoveIMG — minimal, plug-and-play:

Icon-only sidebar (3 cycle buttons: Tool, Style, Strength)
Tap detected faces/text to toggle blur
Manual brush for anything auto-detect misses
3 blur styles: pixelate, gaussian, black box
3 intensities: light, medium, heavy
Oval + rectangle brush shapes
What I learned
Client-side ML is viable — SSD MobileNet V1 runs in ~2-3 seconds in a real browser. TensorFlow.js + WebGL makes it fast.
Tesseract struggles with photo-embedded text — it's trained on documents, not scene text. Upscaling + grayscale + contrast normalization helps a lot, but it won't match server-side Vision APIs. That's the privacy tradeoff.
Multi-scale detection matters — single-pass face detection misses small background faces. Running on quadrants (2x zoom) catches them.
Web Workers are essential — OCR and ML inference must run off the main thread or the UI freezes.
Try it
BlurIt is live and free: https://blurit-lime.vercel.app
Open source: https://github.com/JeffreyHamilton6399/blurit

Your photos are yours. BlurIt just helps you protect them. 🛡️

Every link you share has trackers in it (here's how to clean them)

Jeffrey Hamilton — Tue, 28 Jul 2026 14:00:00 +0000

Have you ever copied a link from an email newsletter or an ad and pasted it into a chat? If you look closely at that URL, you'll see a massive tail of tracking parameters: utm_source, fbclid, gclid, mc_cid.

When you share that link, you're sharing tracking data. You're telling Facebook, Google, or Mailchimp exactly who clicked what, and from where.

So I built LinkClean — it strips all tracking parameters from URLs instantly. No sign-up, no tracking, works entirely in your browser.

Try it: https://linkclean-seven.vercel.app
Source: https://github.com/JeffreyHamilton6399/linkclean

How it works
Paste a URL (or a batch of URLs, one per line)
See the clean URL instantly
See what was removed — LinkClean tells you exactly which trackers it stripped
Copy the clean link with one click
It strips 40+ tracking parameters including:

Google: utm_source, utm_medium, utm_campaign, utm_term, utm_content
Facebook: fbclid, fb_action_ids, fb_ref
Google Ads: gclid, gclsrc, dclid
Mailchimp: mc_cid, mc_eid
Microsoft: msclkid
Amazon: tag, linkCode, linkId, camp
...and many more
The architecture
Zero backend. It's a static site hosted on Vercel. The URL cleaning happens entirely in your browser using the native JavaScript URL API.

All computation is synchronous (instant results)
Zero dependencies (the app is tiny)
Batch mode: clean 100+ URLs instantly
No tracking, no analytics, no ads
The privacy model
100% client-side — URLs never leave your browser
Zero network requests
No accounts, no tracking, no analytics
Open source — read every line of code
Try it
Live: https://linkclean-seven.vercel.app
Source: https://github.com/JeffreyHamilton6399/linkclean

Stop sharing tracking data when you share links.

Every photo you share online has hidden GPS data in it (here's how to fix that)

Jeffrey Hamilton — Tue, 21 Jul 2026 14:05:00 +0000

Every time you take a photo with your phone, it bakes invisible data into the file. This includes:

Your exact GPS coordinates (accurate to a few meters)
Your phone model and settings
The exact date and time
Sometimes your name and copyright info
When you post that photo to social media, a forum, or a listing, you're sharing all of that data with the world. Stalkers, doxxers, and data brokers exploit this constantly.

So I built ExifErase — it strips all hidden metadata from your photos before you share them. No uploads, no sign-up, 100% free.

Try it: https://exif-erase.vercel.app
Source: https://github.com/JeffreyHamilton6399/ExifErase
How it works
Drop a photo (JPEG, PNG, WebP, HEIC from iPhone)
See what's hiding — ExifErase shows you the exact GPS, camera, and date data embedded in the file
Erase it — one click strips all metadata
Download the clean photo
The best part: the stripping happens via the Canvas API. When you re-encode an image to a canvas, the metadata simply doesn't carry over. Your file comes out completely clean.

The privacy model
100% client-side — photos are processed in your browser
Zero network requests — your photos never leave your device
No accounts, no tracking, no analytics
Open source — read every line of code
Why this matters
If you post a photo of your house, your kid, or your car online, you're also posting a map to your location. ExifErase makes sure that doesn't happen.

Try it
Live: https://exif-erase.vercel.app
Source: https://github.com/JeffreyHamilton6399/ExifErase

Your photos are yours. The data inside them shouldn't be shared without your knowledge.

I got tired of 15 ad-filled dev tool websites, so I built one clean page

Jeffrey Hamilton — Tue, 14 Jul 2026 14:00:00 +0000

Every time I need to format JSON, decode a JWT, or generate a UUID, I end up on a different sketchy, ad-heavy website. I got tired of closing popups just to format my code.

So I built DevToys — 40 essential developer tools in one clean, fast, single page. No ads, no sign-up, no tracking.

🔗 Try it: https://devtoys-nu.vercel.app
📦 Source: https://github.com/JeffreyHamilton6399/devtoys

What's inside
40 tools including:

JSON Formatter — pretty/minify/validate
Base64 — encode/decode
JWT Decoder — header, payload, signature
Regex Tester — live match highlighting
UUID Generator — batch generation
Hash Generator — MD5, SHA-1, SHA-256, SHA-512
Color Converter — HEX ↔ RGB ↔ HSL
Timestamp Converter — Unix ↔ human date
Cron Parser — human-readable schedule
Diff Checker — line-by-line comparison
...and 30 more (URL encoder, Lorem Ipsum, etc.)
The architecture
Zero backend. It's a static site hosted on Vercel. Every tool runs entirely in your browser using native JavaScript APIs.

All computation is synchronous (instant results)
Zero heavy dependencies (tiny bundle, loads immediately)
No tracking, no analytics, no ads
Mobile responsive
Try it
🔗 Live: https://devtoys-nu.vercel.app
📦 Source: https://github.com/JeffreyHamilton6399/devtoys

Bookmark it and never look for a dev tool website again.

I built a background remover that doesn't upload your photos (no $40/month)

Jeffrey Hamilton — Tue, 07 Jul 2026 19:21:49 +0000

Remove.bg is a great tool, but it has a problem: they upload your photos to their servers. For personal photos, product images, or sensitive pictures, that's not ideal.

So I built Cutout — an AI background remover that runs entirely in your browser. No backend, no uploads, no sign-up, no $40/month subscription.

Try it: https://cutout-murex.vercel.app
Source: https://github.com/JeffreyHamilton6399/Cutout

How it works
The app uses @imgly/background-removal, a powerful AI library that runs directly in the browser via WebAssembly.

When you drop an image:

The AI model downloads (one-time, ~40MB, then cached by the browser)
The model runs locally via WebGPU/WASM to segment the foreground
The background is removed, leaving a transparent PNG
You download the result
Your photo literally never leaves your device. There is no server.

Features
Instant removal: Drop a photo, get a transparent PNG in seconds.
Batch mode: Remove backgrounds from multiple images at once.
Background replacement: Keep it transparent, or add a solid white/black background for JPEG export.
Manual refine: If the AI isn't perfect, use the eraser/restore brush to clean up edges.
The privacy model
100% client-side — photos are processed in your browser
Zero network requests during processing (except the one-time model download)
No accounts, no tracking, no analytics
No server-side storage — there IS no server
Open source — read every line of code
Try it
Live: https://cutout-murex.vercel.app
Source: https://github.com/JeffreyHamilton6399/Cutout

Feedback welcome — happy to answer questions about the WASM model or the architecture.

File converter that never uploads your files?

Jeffrey Hamilton — Fri, 26 Jun 2026 17:13:59 +0000

Every online file converter — from Zamzar to CloudConvert to FreeConvert — does the same thing: they upload your files to their servers, convert them, and send them back.

For personal photos, videos, and sensitive documents, that's not great.

So I built ConvertIt — a file format converter that runs entirely in your browser. No backend, no uploads, no sign-up.

What it converts
Images: PNG ↔ JPEG ↔ WebP ↔ AVIF, HEIC → anything, GIF → video
Video: MP4 ↔ WebM, MOV → MP4, any video → extract audio
Audio: WAV → MP3, FLAC → MP3, M4A → MP3, any audio → MP3
Documents: PDF → images (PNG/JPEG), images → PDF, SVG → PNG
How it works
File type Engine How
Video ffmpeg.wasm Compiled to WebAssembly, runs in-browser
Images Canvas API + OffscreenCanvas Re-encode to target format
Audio Web Audio API + lamejs Decode → re-encode to MP3
PDF pdf-lib + pdfjs-dist Render pages or combine images
The architecture
Zero backend. It's a static site hosted on Vercel. There is no server — your files are processed entirely in the browser.

Browser (your device)
├── Drop file
├── Auto-detect input format
├── Show available output formats
├── Convert entirely in memory (Blob URLs)
└── Download result
↳ Files NEVER touch a server

Key technical decisions

1. Lazy-loaded heavy dependencies
ffmpeg.wasm is 32MB. We don't load it until you actually convert a video. Same for pdf-lib (PDFs) and heic2any (iPhone photos). Initial page load stays fast.

2. Auto-detection & routing
Drop a file → the app detects the format by extension and MIME type → shows only the relevant output formats. You can't convert a PNG to MP3, so we don't show that option.

3. Mobile memory safeguards
Mobile devices get stricter file size limits (100MB for video vs 500MB on desktop), and ffmpeg is terminated after each conversion to free memory.

4. Never return a larger file
If a conversion somehow makes a file bigger (rare, but happens), we warn the user but still allow it.

The privacy model

This is the whole point:

100% client-side — files are processed in your browser
Zero network requests during conversion
No accounts, no tracking, no analytics, no cookies
No server-side storage — there IS no server
Open source — read every line of code

Your files are yours. They shouldn't need to visit a server to be converted.

Try it

Live: https://convertit.vercel.app

Source: GitHub

Feedback welcome — happy to answer questions about the architecture or the ffmpeg.wasm setup.

I built a file compressor that never uploads your files (ffmpeg.wasm + Canvas + Web Audio)

Jeffrey Hamilton — Wed, 24 Jun 2026 16:57:12 +0000

I kept using online file compressors and realized they all upload your files to sketchy servers. For tax PDFs, personal photos, and sensitive documents — that didn't feel right.

So I built ShrinkRay — a file compressor that runs entirely in your browser. No backend, no uploads, no sign-up.

Try it: https://shrink-ray.vercel.app
Source: GitHub

What it compresses
Images: PNG, JPEG, WebP, AVIF, HEIC (iPhone photos), GIF, BMP
Video: MP4, WebM, MOV, MKV, animated GIF (via ffmpeg.wasm)
Audio: MP3, WAV, OGG, M4A, FLAC, OPUS
PDF: Re-renders pages as compressed images
3D Models: GLB, GLTF, STL, OBJ, PLY, FBX — with format conversion via Three.js
SVG: Minification (strips metadata, comments, whitespace)
Text/Code: JSON, HTML, CSS, JS, XML, YAML — minified + gzipped
Anything else: Gzip compression
How it works
File type
Engine
How
Video ffmpeg.wasm Compiled to WebAssembly, runs in-browser
Images Canvas API + OffscreenCanvas Re-encode at chosen quality/format
Audio Web Audio API + lamejs Decode → re-encode to MP3
PDF pdf-lib + pdfjs-dist Render pages → rebuild with compressed images
3D Three.js Format conversion (STL→GLB, etc.) + gzip
Text/Code Native JS + fflate Minify (strip comments/whitespace) → gzip

The architecture
Zero backend. It's a static site hosted on Vercel. There is no server — your files are processed entirely in the browser using WebAssembly and Canvas APIs.

text

Browser (your device)
├── Drop file
├── Auto-detect type (image/video/audio/pdf/3d/text)
├── Route to correct engine
├── Process entirely in memory (Blob URLs)
└── Download result
↳ Files NEVER touch a server
Key technical decisions

Lazy-loaded heavy dependencies

ffmpeg.wasm is 32MB. We don't load it until you actually drop a video. Same for Three.js (3D), heic2any (HEIC photos), and pdfjs (PDFs). Initial page load stays fast.

Multi-threaded ffmpeg when available

On browsers with SharedArrayBuffer (COOP/COEP headers), ffmpeg uses multiple CPU cores via Web Workers. Falls back to single-threaded automatically.

Pre-warm on desktop, skip on mobile

On desktop, ffmpeg starts loading the moment the page opens (so it's ready when you drop a video). On mobile, we skip this — the 32MB download would freeze low-RAM devices.

Never return a larger file

If compression makes a file bigger (happens with already-compressed files), we return the original instead. You never download a file larger than what you uploaded.

Mobile memory safeguards

Mobile devices get stricter file size limits (100MB for video vs 500MB on desktop), and ffmpeg is terminated after each conversion to free memory.

The privacy model
This is the whole point:

100% client-side — files are processed in your browser
Zero network requests during compression
No accounts, no tracking, no analytics, no cookies
No server-side storage — there IS no server
Open source — read every line of code
Your files are yours. They shouldn't need to visit a server to be compressed.

Try it
Live: https://shrink-ray.vercel.app
Source: https://github.com/JeffreyHamilton6399/ShrinkRay

Feedback welcome — happy to answer questions about the ffmpeg.wasm setup, the 3D conversion pipeline, or the architecture.