Papaya PDFAlmost every frustration with editing a PDF traces back to one fact: the format was never meant to be edited. It was meant to make sure a page looks the same wherever it is printed or displayed. Everything that makes PDFs reliable is the same thing that makes them stubborn.
Where PDF came from
PDF grew out of PostScript, the page description language Adobe introduced in the early 1980s. PostScript let a computer describe a page precisely enough that a laser printer could draw it: here is a curve, here is a block of text in this font at this size, here is where each line begins. It helped launch desktop publishing because the same file produced the same page on any compatible printer.
By the early 1990s the problem had moved from printers to screens and email. People wanted to send a finished document to someone with a different computer, different fonts, and different software, and have it arrive looking exactly as intended. Adobe's answer was the Portable Document Format, released in 1993 with the first Acrobat products. PDF kept PostScript's imaging model but dropped the programming language, packaging fonts, images, and pages into one self-contained file with an index, so any page could be found and drawn without running a program.
Over the following decades PDF became an open standard (ISO 32000, in 2008), and a family of specialised profiles grew around it: PDF/X for print production, PDF/A for long-term archiving, and PDF/UA for accessibility. These are mostly about preserving, validating, and delivering a page, not about changing one.
A PDF is a set of drawing instructions
Open a PDF's page and you do not find paragraphs. You find a content stream: move here, set this font, draw these glyphs, paint this image, stroke that line. A "line of text" might be a single instruction or twenty. A "paragraph" does not exist anywhere in the file; a reader infers it from where the lines sit. A table is often just text placed at the right coordinates next to thin ruled lines. There is no row three, only ink positioned so that a human sees row three.
Fonts add another layer. To keep files small, a PDF usually embeds only the glyphs the page actually uses. If you want to type a letter that was never on the page, the font may not contain it. Our post on the hidden font problem goes deeper into that.
This was a feature. A page that cannot reflow cannot break. The same design that guarantees a contract prints identically in every office also guarantees that a word processor's idea of "select a paragraph and retype it" has nothing to attach to.
Most PDFs are exports, not originals
Very few people sit down and write a PDF by hand. Nearly every PDF you receive was produced by another program: a word processor's "Save as PDF", a browser's "Print to PDF", a spreadsheet, a design tool, an accounting or billing system, a scanner. In each case the real document lived somewhere else, with its own structure: paragraph styles, heading levels, real table definitions, page margins, reflow rules, live formulas, and the data behind a receipt.
Exporting to PDF is the last step, and it is lossy on purpose. The exporter takes that rich source, lays it out one final time, and writes down only the result: glyphs at coordinates, lines, and images. The styles, the table model, and the intent that produced the layout are not carried along. Some exporters add accessibility tags that keep part of the structure, but many do not, and the tags that exist are often incomplete.
So when you open a PDF to fix a typo, you are not editing the original. You are looking at the printed output of a document whose source is somewhere you cannot reach, and often no longer exists. That is exactly the situation a reverse engineer faces with a compiled program, and it is why we approach PDFs the way we do.
The usual workarounds
Because the structure is missing, most PDF editors take a shortcut. Some paint a white box over the old words and place new text on top. Some convert the page to an image and let you annotate it. Some convert the whole document to a Word file and ask you to hope the layout survives. These approaches treat the PDF as something to get around rather than something to understand. We compare them in true text editing vs visual PDF editors.
Our approach: treat it as reverse engineering
We started from a different question. If the structure a human sees is still recoverable from the page, then editing a PDF is not a file-conversion problem. It is a reverse-engineering problem: given the finished output, work backward to the intent that produced it.
That means building a real PDF engine, written in Rust, that parses and renders the page itself and then recovers the pieces an editor needs.
Source text and fonts
Which glyphs belong to which run, in which font, at what position, so an edit can replace the original text instead of covering it.
Layout
Which lines belong together, where columns and alignments sit, and what a sensible reflow would be.
Tables
Where the grid is, including tables that have no ruled lines at all, so cells and rows become objects you can edit.
Scans
For pages that are only images, recognized text and a layout that can become searchable or editable content.
Wherever a PDF carries real signal, we use it first. Glyph positions, text matrices, font resources, ruling lines, clipping, and tagged structure are exact facts, and they do not need to be guessed from pixels. Tagged PDFs sometimes even declare their tables outright.
Where AI helps, and where it does not
The ambiguity is where the work gets hard. Is that column of numbers a table or a list? Where does a borderless table end? What is this word in a blurry scan? Those are perception problems, and learned models are good at perception.
So we use AI as an assistant to the engine rather than as its replacement. The engine remains the source of truth: it checks every proposal against what the PDF actually contains, keeps track of which original content each lifted edit replaces, and only accepts a structure it can edit, undo, and write back as a normal PDF. A model can suggest a table. The engine decides whether that table is real enough to become one.
In practice that means a layered approach. Deterministic facts from the PDF come first. A learned model helps rank the ambiguous cases. The engine validates the result before anything becomes part of your document. For scans, visual layout analysis and OCR come first, and the same validation comes last.
By default, recognition runs on your device: OCR in the browser on the web, and Apple's Vision framework in the native Apple apps. The web app also has an experimental, optional setting that sends page evidence to larger hosted models for hard tables and scans. It is a Pro feature, it is off unless you turn it on, and it can scramble readable text before upload. The native apps do not use hosted models.
Lessons from reverse-engineering software
We are not the first people to work backward from a finished artifact. Reverse engineers do it with compiled programs every day, and the tools they use, Ghidra, IDA, and Binary Ninja, taught us a lot about how to think about the problem.
A compiled binary, like an exported PDF, is the end of a one-way process. The programmer's variable names, comments, and structure were thrown away on the way to machine code, just as a document's styles and table definitions are thrown away on the way to a PDF. A decompiler cannot get them back. What it can do is analyze the instructions and produce a readable approximation: recovered functions, guessed types, and pseudo-code that reads like the original and approximates what it does, even though it is not the original source.
What these tools do well is accept that. A few ideas carry straight over to PDFs.
Perfect reconstruction is not the goal
Nobody expects a decompiler to return the exact source file. The goal is a useful model that is faithful enough to work with. We hold the same bar for a PDF: recover a structure you can edit, not a guess at the original word-processor file, which is gone.
Build in layers
Binary Ninja moves code through several intermediate representations, and Ghidra lifts instructions into its own intermediate language, so each step can be checked on its own. Our engine does the same with a PDF: raw drawing operations become text runs, lines, and blocks, while ruling lines and aligned text become table candidates, and each layer can be validated on its own.
Keep the evidence
A good disassembler never loses the link between what it shows and the bytes underneath. Our engine keeps every lifted edit tied to the original content it replaces, which is what lets it suppress the old text, undo a change, and save a normal PDF.
Expect to be wrong, and make correction cheap
Analysts rename a function or fix a type and keep working. Our editor lets you lift a region, fix what the engine got wrong, and keep going with one undo history, instead of being stuck with a one-shot conversion.
Use every automated helper, but trust none blindly
Heuristics, signatures, and now learned models all feed reverse-engineering tools as suggestions. The analyst, and the tool's own consistency checks, decide what sticks. That is exactly the role we give AI.
If you demand that every PDF round-trips to a perfect editable document, the project cannot be finished. If you accept that reconstruction is approximate, you can ask better questions: how confident is this guess, what evidence supports it, what happens if it is wrong, and how easily can the user fix it? Those questions produce a better editor than a promise of perfection would.
What this does and does not solve
Born-digital PDFs, the kind exported from a word processor or an accounting system, are where the approach is strongest. Scans depend on image quality and always need a human check on names, dates, and amounts. Table recovery is heuristic and improves with every real document we test. Rewriting a paragraph across a complicated multi-column layout is still being built.
What we can say is that the direction is different. Instead of fighting a format that was designed to stay put, we read it carefully enough to find the document inside, and then give you back a standard PDF that other tools open without complaint.