DEV Community: K Merchant

How I built a PDF editor with zero backend

K Merchant — Tue, 29 Sep 2026 15:00:27 +0000

Every PDF editor you've ever used has a server. You upload your document, it gets processed somewhere you can't see, and a modified file comes back. For tax returns, legal contracts, and medical records, that's a strange thing we've all agreed to.

I kept wondering: how much of a PDF editor actually needs the server? Turns out, almost none of it. So I built one with zero backend. No API, no database, no auth, no analytics. Just static files. Here's how.

The core realization

A PDF is a structured document format, not magic. Rendering it means parsing objects and painting them to a canvas. Editing it means rewriting those objects and re-serializing the file. Every step of that is computation, and browsers are extremely good at computation now. The server was never doing anything the client couldn't do — it was just where developers found it convenient to put the code.

Going serverless wasn't a cost decision. It was the product. If there is no server, there is nothing to breach, subpoena, or monetize. Privacy becomes a property of the architecture instead of a promise in a privacy policy.

The architecture

The app is a static site. index.html, some JS, some CSS. That's the entire deployment. Here's what happens inside:

Rendering. Pages render to <canvas> elements at the device's pixel ratio. There's no text-selection layer — pages are canvas-only with selection disabled to keep touch annotation reliable; the edit tool locates text through its own hit-testing of the content stream instead. Zoom is re-rendering at a higher scale, not image stretching, so text stays sharp.

Editing real text. This is the part most "PDF editors" fake. Many tools let you click on text and type, then export a PDF with your new text drawn on top of the old text — the original bytes are still in the file. Select the text underneath, or extract it programmatically, and the old content is right there.

PDF Studio rewrites the page's content stream on export. When you edit a paragraph, the old text-showing operators are replaced and the file is re-serialized without the original bytes. Old content is gone, not covered up — for text the document's encoding can represent, which is the overwhelmingly common case. (Edge case, stated plainly: replacements in scripts the original font can't encode fall back to painting over the old text.) This distinction matters enormously for redaction (more on that in a moment) and it's the difference between editing a PDF and annotating a screenshot of one.

Forms. The app parses AcroForm field definitions, renders fillable inputs over the page, and on export can either keep fields live or flatten them into static page content. Flattening matters when you're sending a form to someone who shouldn't be able to change the answers.

Redaction, done honestly. A lot of redaction tools draw a black rectangle over sensitive text and call it done. The text is still in the file — anyone can select it, copy it, or extract it. Proper redaction means removing the text from the content stream entirely and burning the black box into the rendered page. That's what this does: the export contains no trace of the redacted content. I wrote a separate guide on verifying this (linked at the end), because "trust me" is not a redaction strategy.

OCR on-device. Scanned PDFs get OCR through a WebAssembly build of Tesseract running in a Web Worker, so the UI never blocks. The language data downloads once and caches locally. Your scanned document never leaves the machine — which is the entire point, since scanned documents are disproportionately the sensitive kind (signed contracts, IDs, medical forms).

State and undo. All document state lives in memory with a full undo/redo stack, and the app quietly autosaves your session to your own browser's local storage — never a server — so you can pick up where you left off. Export is just the browser downloading a file it built locally, and one click wipes the saved session from the device entirely.

The hard parts

Memory. A 200-page PDF with embedded fonts can eat serious RAM when every page holds a canvas. The discipline so far: cap render resolution, cancel stale render tasks the moment you zoom, keep per-page work cheap. Full viewport culling — only rendering pages near the visible area — is still on the roadmap. Mobile forced this discipline — phones have no patience for desktop memory habits.

Text editing fidelity. Replacing text in a content stream while preserving the surrounding layout means understanding the text-showing operators, the font encodings, and the positioning math. PDFs position glyphs with explicit coordinates, not flow layout. Editing a line of text is closer to surgery than word processing: you remove the old showing operations, compute where the replacement goes in the same coordinate space, and write new operations that the next renderer will interpret identically.

Mobile. The recent overhaul was the biggest single chunk of work. Touch-based annotation, dialogs that fit phone viewports, a top bar that scrolls internally instead of overflowing the page at tablet widths. Sixteen markup tools had to work with fingers, not cursors. The lesson: mobile isn't a smaller desktop, it's a different input paradigm, and every interaction needs rethinking.

The service worker trap. The app works offline via a service worker, which is great for users and terrible for developers: during testing I repeatedly "verified" fixes against a stale cached bundle. If you ship an offline-capable app, build bundle-hash verification into your QA process or you will chase ghosts.

What I'd do differently

I'd have designed the export pipeline around incremental saves earlier. Right now export re-serializes the whole document, which is fine for typical files but wasteful for 500-page reports where you changed one word. That's the next architectural project.

Try it / tear it apart

It's free and MIT-licensed: https://navigatorslab.com/pdf-studio/
Source: https://github.com/Kayforkind/NavigatorsLab-PDF-Studio

No signup, no tracking — there's genuinely nothing to sign up for. If you find a PDF it chokes on, that's the most useful bug report you can file.

The verification guide: https://dev.to/kayforkind/how-to-properly-redact-a-pdf-so-the-text-is-actually-gone-5alf

How to properly redact a PDF so the text is actually gone

K Merchant — Tue, 29 Sep 2026 14:18:07 +0000

Drawing a black rectangle over sensitive text in a PDF does not redact it. I need you to understand this before anything else, because people get fired, sued, and embarrassed over this exact mistake.

A PDF is not an image. When you draw a black box over text, you're adding a new object on top of the text. The text is still there, in the file, in the content stream, fully selectable, copyable, and extractable. Anyone who selects the "redacted" area and pastes it into a text editor gets your secrets. Anyone who runs a text-extraction script gets all of them at once.

This has happened to governments, law firms, and newspapers. It's not a theoretical risk.

The 30-second test

Before trusting any redaction, do this:

Open the "redacted" PDF.
Try to select the text underneath a black box with your cursor.
Copy it. Paste it into a text editor.

If anything pastes, the redaction failed. It doesn't matter what the tool promised. The file is the truth.

For a stronger check, run a text extraction tool over the whole document and search the output for the sensitive terms. If they appear, the content stream still contains them.

What proper redaction actually means

Real redaction has two parts, and both are required:

Remove the content from the file. The text-showing operations for the sensitive content must be deleted from the page's content stream — not covered, deleted. The bytes should not exist in the exported file.
Burn the visual mark into the page. The black box should be part of the rendered page content, so the document still reads naturally with visible redaction marks.

If a tool only does step 2, it's a highlighter with bad intentions.

How to do it properly (step by step)

Using PDF Studio (free, runs in your browser, no signup — and relevantly, your document never uploads anywhere, which matters when the document needs redacting):

Open https://navigatorslab.com/pdf-studio/ and load your PDF. Nothing uploads; everything happens on your machine.
Select the redaction tool and mark every piece of sensitive text. Marked regions show as a hatched pattern with a dashed red outline labeled "marked for redaction" — that's a promise, not the removal. Be thorough — and don't forget metadata-adjacent content: headers, footers, and text baked into scanned images needs OCR-aware handling.
Export the PDF — that's when the actual destruction happens, not in the editor. The export clears hidden copies (form values, annotations, structure-tree text) under the marked regions, deletes the vector text operations from the content streams (recursively through Form XObjects), pixel-burns anything it can't provably remove (partial text coverage forces a full-page raster replacement), scrubs metadata/XMP/attachments/JavaScript/actions, and refuses the export entirely if any covered text survives — then burns in the black boxes.
Verify. This step is not optional. Open the exported file, try the 30-second select-and-copy test on every redacted region. Then run text extraction across the whole document and search for the sensitive terms. They should be absent.
Check the document metadata too (File → Properties in most readers). Author names and revision history have leaked through "redacted" documents before.

What about scanned documents?

If your PDF is a scan (an image of a page, not real text), there's no text layer to leak — but there's also no text to redact selectively. The safe approach: redact regions of the image itself, so the pixels are destroyed, not covered. Covering part of an image with a black box in a PDF is the same lie in a different format — the underlying image object still contains the original pixels. Make sure your tool destroys the pixels, then verify by extracting the images from the exported file.

The rule

Never trust a redaction you haven't verified. Not from my tool, not from anyone's. The 30-second test takes less time than reading this article. If a tool fails it, stop using that tool for sensitive documents immediately.

PDF Studio redacts by removing content from the file's content stream on export — then invites you to verify it with the test above. Free, MIT-licensed, no server, no signup: https://navigatorslab.com/pdf-studio/

reimagine-it v2.4.3 — one command, every page's CSS restored

K Merchant — Thu, 27 Aug 2026 00:12:00 +0000

🛠️ v2.4.3 — every generated page just got its CSS back

This release fixes the deepest bug the engine has ever shipped: every token was embedding a literal undefined where its shared CSS should be. The token dispatcher ran before the engine built its CSS systems, so pages silently lost their mesh aurora fields, giant data-wash numbers, glyph tiles, donut charts, stats bands, bento grids, and band marquees/footers — while still passing the craft audit (the audit inspects body markup, not CSS). One command, one-line fix, and every output grows its full art system:

No more undefined in any of the 15 tokens — outputs grew by the complete band/art CSS (a webpage render went 15 KB → 24 KB).
Background numbers no longer glue together — 336,000 + 40,000 used to render as one clipped 336,00040,00; they now spread, cap at 32vw, and ellipsize on phones.
The webpage token's isometric stamp floats again — it was the only token missing the shared art CSS.
Palette gate fixed — source brand hexes like #FF3366 no longer count as two colors when the engine lowercases them into CSS vars; a 1500-cell sweep (100 sources × 15 tokens) passes 100% with 0 errors, fidelity avg 99.6%.
Regression-locked — a new unit test fails if any token output ever embeds a literal undefined or drops its shared CSS systems again (59/59 tests green).

All seven end-user examples, the gallery, and the live playground were regenerated through the fixed engine — the visuals on kayforkind.github.io/reimagine-it are what the engine actually produces now.

What it is

reimagine-it is a one-command agent skill that redesigns an existing HTML file into a beautiful, working artifact — using only the nouns, dates, colors, links, and numbers already in that file. No mood boards, no gold layouts with swapped labels. The output is a real page you can open.

npx reimagine-it@2.4.3 -i mypage.html -o redesigned.html

What's new in v2.4.2

1. Source fidelity floor raised to 80% across every token

Before v2.4.2, 61 of 105 token×source cells fell below 80% fidelity — the engine preferred headings over real source anchors, so phrases like "Venator Become" or "Arcade Tee" never rendered. Now:

Anchors = headings + source anchors, deduplicated — every clickable phrase survives.
All 105 token×source cells ≥80% (worst token: 80%).
All seven shipped examples report 100% fidelity in their auto.json reports.

2. Links and emails surface on every token

A shared Source-index footer renders all content.links and emails on every generated page — not just the webpage/landing tokens.

3. All 15 design tokens in the browser extension

The popup now exposes all 15 tokens: webpage, landing, dashboard, infographic, cinematic, artistic, photography, svg, 3js, simulation, glass, editorial, motion, gradient, showcase.

4. Docs can't drift anymore

A new docs-drift CI job regenerates the case tables and fails the build if they diverge from ground truth.

The 15 design tokens

Token	What it builds
`webpage`	Clean content-first page
`landing`	Conversion-focused landing
`dashboard`	KPI dashboard from facts
`infographic`	Paper-poster argument
`cinematic`	Film-poster energy
`artistic`	Expressive art direction
`photography`	Photo-led layout
`svg`	Living SVG mark
`3js`	WebGL orbit scene
`simulation`	Interactive timeline
`glass`	Glassmorphism UI
`editorial`	Magazine layout
`motion`	Animated micro-interactions
`gradient`	Bold gradient arena
`showcase`	Product showcase

Measured, not vibes

57/57 unit tests pass
15-token benchmark: all tokens hold the 100/100 usability bar
100-source stress test: 0 errors, fidelity avg 99.7, min 80
7 end-user examples at 100% fidelity

Try it — no install

Live gallery (no install): https://kayforkind.github.io/reimagine-it/
Repo: https://github.com/Kayforkind/reimagine-it
npm: npx reimagine-it@2.4.3

Give it one HTML file. It gives you back something worth opening.