I built 4 PDF editors in 12 months. The boring one finally shipped.

Last February, I made one commit that threw away nine months of code.

Gone: a Flask backend, a Tiptap document editor, a Gemini multimodal pipeline, three different PDF-to-HTML conversion experiments. In its place: one engine that edits PDF bytes directly in the browser.

It's called Folio — pdf-editor.online, a Chrome extension and web app. You click a word in your invoice, type a new one, hit save. Same font, same position, same bytes everywhere else.

But that wasn't the first thing I tried. It was the fourth.

Iteration 1: the Fabric.js overlay (early 2025)

The first build took what felt like the obvious approach. The user clicks text on a rendered PDF. The editor extracts that text and its coordinates via pdf-lib, drops a Fabric.js text box at the same position with the same font and size, masks the original with a white rectangle, and lets the user edit freely. The white mask and the new text were both independently draggable, the way a Figma or Sketch user would expect.

On a single-page document, the illusion held beautifully. I demoed it to a friend and felt great.

Then I tried a 3-page lab report.

PDF page coordinate systems aren't uniform. The origin can shift. Rotation matrices apply. CropBox and MediaBox differ. Fabric.js doesn't natively understand any of this, so position calculations that were pixel-perfect on page 1 drifted by several lines by page 3.

Worse — and this is the part I should have caught sooner — on save, the editor flattened the Fabric.js canvas into an image and overlaid it onto the original PDF via pdf-lib. The output wasn't an edited PDF. It was a PDF with an image of edited text sitting on top of the original PDF. Open it in a different reader, print it at higher resolution, or diff it against the original, and the lie became obvious.

I patched coordinate math for weeks — every commit some version of "fix: save bug, again" — before I admitted the foundation was wrong.

Iteration 2: the Gemini multimodal pipeline (mid-2025)

Hard pivot. If editing PDFs in place was too hard, convert them to clean HTML, edit the HTML in Tiptap, then re-export back to PDF.

The conversion was the interesting part. Standard PDF-to-HTML libraries like pdfminer and pdfplumber gave you readable text but lost the layout — multi-column reports turned into one long paragraph. So I tried Google's Gemini multimodal model. Fed it page images. Asked for semantic HTML.

The results were genuinely impressive. Gemini understood column structure, table boundaries, header hierarchy, even color-coded sections in lab reports. Honestly the best PDF understanding I'd seen, AI or otherwise.

So I built it out. Custom Tiptap extensions. AI-assisted document editing. A PDF import-export pipeline on a Flask backend. The product was finally doing something nothing else free could match.

And then I had to start disabling things, one by one. PDF-to-Word conversion went first — Vercel's serverless size limit. Then the import pipeline started returning errors during normal traffic.

Here's what broke: cost.

Folio was a free product from day one. Every upload was a Gemini API call — roughly $0.02 for a 5-page invoice, twenty cents for a 100-page contract. For a free tool with the ambition to serve real volume, this was an existential expense.

I tried a free-tier limit of three conversions per day. Users immediately bumped against it. I never enabled paid plans because the product hadn't proven itself yet. Then Gemini's free quota started returning 429s during normal traffic. Users opened the upload dialog and saw Backend returned 500: 429 Gemini quota. Meanwhile, the Flask backend hit Vercel's serverless function size limit. Everything was on fire simultaneously.

Iteration 3: library-based conversion, no AI (late 2025)

Drop the AI. Use pdfplumber server-side to extract text, positions, and font info deterministically. Render to clean HTML. Edit in Tiptap. Re-export with pdf-lib. No model calls, no quota errors, predictable cost.

This was supposed to be the answer.

What broke: the round trip lost fidelity. The HTML rebuilt from pdfplumber's output looked close to the original — but Tiptap is a paragraph-based editor, not a layout editor. The moment a user edited anything more complex than a single line of text, the HTML-to-PDF mapping cracked. Kerning shifted. Fonts substituted to system defaults. Columns realigned. Tables collapsed.

I shipped this version and used it myself for two weeks. Every PDF I edited came out subtly wrong — kerning a little off, line height slightly different, an invoice with a name change that looked like a different invoice. The "edit" had quietly become a "rewrite," which wasn't the contract I wanted to ship.

Iteration 4: just edit the bytes (early 2026)

Back to first principles. I sat down with the PDF 1.7 spec one more time, and this time I actually read it.

Here's the realization that should have come earlier: PDF content streams are editable in place if you just edit the bytes.

A Tj operator that draws $317.40 can be rewritten to draw $317.50 by changing a single byte in the content stream — the 4 becomes a 5. Every other byte stays untouched. No conversion. No round-trip. No fidelity loss. The original embedded fonts stay in the file, so the new text picks them up automatically.

pdf-lib could do this in principle via its low-level object-model API. The hard part wasn't writing the bytes — it was finding the right bytes to write to. Because every PDF generator on Earth emits text in a different shape.

Quick vocabulary, since the table is dense. A PDF page is a tiny program of drawing instructions — that program is called a content stream. The two operators that draw text are Tj (show a string) and TJ (show an array of strings with spacing between them). The string itself can be written as a literal — (Hello) Tj — or as hex — <48656C6C6F> Tj, where each byte pair maps to a character. Some generators wrap a whole word in one operator. Others split every letter into its own. All of them render identically when you open the file.

Here's the variety:

These all render identically to the eye through pdf.js. At the byte level they're seven different problems.

The current engine has seven substitution passes, applied in order of specificity. Each handles one of the shapes above. Most browser-based PDF editors handle passes 1 and 2 — the easy ones — and silently fail on the rest, which is why "edit any PDF, free" landing pages tend to fall apart the moment you feed them anything from a real enterprise toolchain.

The seventh pass was the hardest. I added it at 2 AM while debugging a real lab report from a medical center. Every visible character of ANAS, DIRECT BILIRUBIN, SGPT was wrapped in its own one-glyph TJ array inside a single BT…ET block — the begin-text / end-text markers that bracket a section of text drawing in the content stream. None of the previous six passes could touch it. Phase 7 walks adjacent arrays, joins their decoded text across font boundaries, finds the matching subsequence, and rewrites the first slot.

The whole pivot landed in one big commit. The day the Flask backend, the Tiptap editor, the HTML conversion pipeline, the Gemini integration, and a frankly embarrassing amount of UI scaffolding all got thrown away.

What followed was eight weeks of what I came to think of as "fixing the things we lied about." The upload flow still tried to ping the dead Flask backend. The .env.example still listed Gemini keys. The editor toolbar clipped on mobile. And — my favorite — the upload dialog still said "Deterministic engine first — receipts and tables don't need AI. We'll only call the model if confidence is low." That sentence was doubly false: the model was gone, and the receipt heuristic had been retired the week before.

The instinct to delete every false claim from the UI the moment you notice it became one of the policy decisions that shaped the rest of the product. That's why the Chrome Web Store listing still has a section called "Things Folio does NOT do (yet)" right under the marketing copy: no whiteout, no image insert, no annotations, no page reorder, no scanned-PDF editing. People keep telling me that section is the most-read part of the page. Apparently "I can't do this" is the cheapest trust signal on the internet.

Around the same time as the engine rewrite, I also tore down the entire UI and rebuilt it with Claude — forest-green accent on paper tone, a custom brand mark that holds together from 16-pixel favicon to marquee promo tile. But that's a different post.

So that's where it landed. pdf-editor.online, a Chrome extension and web app. The extension does one thing: opens the web app in a new tab. One Chrome permission (tabs), no host access, no content scripts, no telemetry. The web app does the work. You click any text in a rendered PDF, type a new word, save. For digital PDFs — invoices, contracts, lab reports, receipts — the output is byte-identical to the original except for the characters you changed. You can xxd it against the source if you don't believe me.

You'll need an account to upload a PDF, but the editing itself happens in your browser. Your file content doesn't go through our backend; it sits in your own private Supabase Storage bucket, only readable by you. No AI runs on the edit path. The substitution engine has 82 unit tests across all seven encoding shapes, and I add a new one every time someone sends me a PDF that breaks it.

The fourth iteration is the one that shipped. The first three were the price.

If you find a PDF that breaks it, send it — that's how phase 7 got built.