How it works, and how we know it works
Most editors ask you to trust that your layout survives. This page explains the mechanism, states what it can’t do, and gives you the numbers — all of which you can check.
The numbers
Every figure here is produced by running something in our codebase, not by an estimate. That is the only kind worth publishing.
- 184automated testsRun on every change, including security suites
- 43files in the test corpusReal documents: invoices, CVs, brochures, legal, Arabic
- 0.8%page change on a one-line editPixel-diffed; the build refuses to publish above 15%
- 0bytes of the original rewrittenAsserted: the original must be an exact prefix
What happens to your file
Five steps. The important one is the last: your file is added to, not rebuilt.
- 1
Render
The page you see is drawn by PDFium from your original file — not an approximation rebuilt in HTML. What is on screen is what the PDF says.
- 2
Index
A separate read-only pass maps the editable regions: each text run with its font, size, colour and position, and each image with its placement rectangle. Nothing is modified.
- 3
Resolve
When you click, the run under the cursor is resolved by position. If a request cannot be resolved to a specific run, the edit is refused rather than applied to a guess.
- 4
Rewrite
The run’s text-showing operators are removed from the content stream and replacements written in their place, reusing the document’s own embedded font where the glyphs exist.
- 5
Save
Changed objects are appended to the end of the original file with a new cross-reference section. The bytes before them are untouched.
Why this differs from conversion
A converter has to reconstruct meaning that the PDF does not contain. Nothing in the file says “this is a table” or “this is a two-column layout” — that structure is inferred from where the glyphs happen to sit. The inference is right often enough to be tempting and wrong often enough to cost you a document.
Editing the objects directly skips the inference. We do not need to know that something is a table, because we never redraw the table. We replace one run of text and leave every other instruction on the page exactly as it was. There is no layout engine to get it wrong, because no layout is re-run.
The trade is honest and worth stating: you get precision on corrections, and you do not get restructuring. If you need to add a row or re-flow a paragraph, this is the wrong tool and the PDF creator is the right one.
What is and isn’t supported
The second half of this list is the useful half — and it is the half most tools leave out.
- Left-to-right text runs in an embedded font
- Text whose replacement glyphs exist in the embedded subset
- Classic cross-reference table originals (incremental append)
- Per-glyph text (Chromium, Canva) when targeted by position
- Pages with several content streams — refused, not guessed
- Cross-reference stream originals — refused with a clear error
- Scanned pages (no text layer to edit)
- Restructuring: adding rows, merging cells, re-flowing paragraphs
How layout preservation is tested
“Preserves your layout” is unfalsifiable as a sentence, so we made it falsifiable. A build script renders a real invoice, edits one line through the same pipeline the site uses, renders the original and the result, and compares them pixel by pixel. It reports the band of rows that changed and the percentage of the page affected.
If the edit fails, or if more than 15% of the page changes, the script exits and writes nothing. The before/after images on the editor page can therefore only exist while the claim they illustrate is true. On the current sample, one line edited changes 0.8% of the page — a 13-pixel band on the line itself, with the table beneath it bit-for-bit identical.
Underneath that sit 184 automated tests and a set of self-checks that assert the properties the product is sold on: that an incremental save leaves the original as an exact byte prefix; that an edit which cannot be located raises instead of writing somewhere wrong; that an orphaned temp file is reaped without waiting for a restart. The corpus is 43 real documents — invoices, CVs, brochures, legal paperwork, Arabic text — rather than files built to pass.
A test that only proves the happy path is decoration. The ones worth writing are the ones that fail when we get lazy.
Where it refuses
A theme runs through the list above: when this editor cannot do something correctly, it stops and says so. A page with several content streams, a cross-reference stream original, a character with no glyph in the embedded subset, an edit that cannot be resolved to a specific run — each returns a clear message instead of a plausible-looking file.
That is a deliberate stance, not missing features. An edit that silently looks wrong is worse than one that refuses, because you only discover the first kind after you have sent the document to a client. Every refusal in this product exists because the alternative was a document that quietly lied.
Current ceiling: 10MB and 100 pages per file. Read the mechanism in detail in the PDF internals reference, or see it run on the editor.
How we check what we publish
Marketing copy drifts away from the product. It happens quietly: a feature gets described optimistically, the description outlives the plan, and a year later the site is promising something that was never built. We have found that on our own pages and removed it. So this site runs to four rules.
- A technical claim is written from the code that implements it. Every entry in the PDF internals reference is traced to the part of the editor it describes before it is written. If we can’t point at the implementation internally, it does not get published.
- A number comes from running something.Not an estimate, not a round figure that sounds good. The 0.8% on the editor page is what a pixel diff measured; the build refuses to publish the images if it rises above 15%. What we don’t publish is how the sausage is made — internal paths and commands are nobody else’s business, and a reader couldn’t run them anyway.
- Limitations are published with the feature, not after the complaint. Every page here has a section on what it cannot do. Those sections are the reason the rest is worth believing.
- A claim about anyone else is quoted from them and dated.Our comparison pages use competitors’ own published wording, with the date we checked it, and no pricing — prices change, and a stale price is a false statement about someone else’s product.
This site is built and maintained by the developer who writes the editor, which is why these pages can cite the implementation rather than describe it from outside. Found something here that is wrong, or out of date? Tell us — a correction is cheaper than a reputation.
Frequently asked questions
Because the thing a word processor edits was discarded when the PDF was made. A PDF does not contain paragraphs and styles; it contains instructions that draw glyphs at fixed coordinates. That is why it looks identical everywhere, and why there is nothing underneath to re-flow. You can change those instructions precisely — which is what this does — but there is no document model to rewrite.
Adding puts something new on top of the page: a text box, a highlight. Editing changes the instruction that draws the words already there. They look the same on screen and are completely different in the file — after adding, the original text is still present, copyable and searchable, sitting under whatever was drawn over it.
By diffing pixels rather than asserting it. Our build renders a real invoice, edits one line through the same pipeline the site uses, renders both files, and compares them. It reports the rows that changed and the share of the page affected — currently 0.8% for a one-line edit, a 13-pixel band. If the edit fails, or more than 15% of the page changes, the build publishes nothing, so the before/after images on the editor page cannot outlive the claim they illustrate.
Most PDFs embed only the characters that document uses. Type a character the file never contained and there is no glyph to draw it. At that point an editor either substitutes a font that has it — quietly, usually — or says something. We embed a metric-similar fallback and report which font was substituted, so the decision is visible rather than discovered later by a client.
Any modification after signing will invalidate that signature — that is what a signature is for, and it is true of every editor, not just this one. Incremental updates are the mechanism signatures use to prove nothing earlier changed; appending your edit is detectable by design.
It stops and tells you. A page with several content streams, a cross-reference stream original, a missing glyph, an edit that can’t be resolved to a specific run — each returns a clear message rather than a file that looks plausible. An edit that silently looks wrong is worse than one that refuses, because you only find the first kind after you have sent the document.
Each PDF can be up to 10 MB and 100 pages. Editing targets left-to-right text in embedded fonts. Scanned pages have no text layer to edit. Restructuring — adding rows, merging cells, re-flowing paragraphs — is out of scope by design, not pending.
It depends entirely on what the service does with the file, which is why we describe the processing model rather than saying “secure”. Editing here runs on bytes in memory and never writes your document to a disk; the converter tools write one short-lived temp file and delete it when the job returns. The details are on the security page.