Open a PDF in most editing tools and something invisible happens before you type a single character: the file is converted into the tool’s internal format. You edit that internal copy, and when you save, the tool writes a brand-new PDF over your original. The file that comes out is a reconstruction — usually close, never guaranteed identical.
GingerDocs takes a different approach, and the difference matters most exactly when documents matter most.
The convert-and-rewrite problem
Conversion is lossy by nature. Fonts get substituted when the editor does not ship the exact typeface. Layouts shift by fractions that compound across pages. And the original file — the one your counterparty actually sent — is overwritten the moment you save.
For a flyer, that is a nuisance. For a contract, it is a real problem: you can no longer prove what the document looked like before you touched it.
The overlay model
GingerDocs renders your PDF read-only, exactly as authored, and keeps every edit on a separate layer above it. Text, signatures, dates, checkboxes, dropdowns — all of it lives in the overlay. The source file is never modified.
Because edits are data rather than baked-in pixels, you get undo/redo on every change and a version history you can roll back through. A flattened PDF is generated only at completion — and even then, as a new artifact alongside the preserved original.
Side by side
| Capability | GingerDocs (overlay) | Convert-and-rewrite editors |
|---|---|---|
| Original file | Kept read-only, always | Overwritten on save |
| Rendering | Exactly as authored | Approximate; font substitution risk |
| Your edits | Separate, editable layer | Baked into the page |
| Edit history | Undo/redo + version history | Often none |
| Audit trail | Every event logged and hash-chained | Not tracked |
When you do need to change the words
Overlay is the default, but not the only mode. When a line needs correcting, in-place editing lets you click the existing text and retype it with the original font and colour matched — changing what is on the page without converting the file underneath it. And when a document genuinely has to be re-authored, an optional reflow mode rebuilds it into editable rich text and renders a clean new PDF.
The difference from a convert-and-rewrite editor is not that GingerDocs never re-renders — reflow does — it is that it never overwrites. Whichever mode you use, your uploaded original is preserved untouched alongside the result, so "what did this look like before?" always has an answer. Reflow is a deliberate, opt-in path for the rare document that needs it, not the step every save quietly runs through.
Why this matters for signed documents
A signature workflow is an argument about authenticity waiting to happen. When the original is preserved, the edits are layered, and every event is in a tamper-evident log, that argument has a short answer. When the file has been converted and rewritten three times before signing, it does not.
If your documents are worth signing, they are worth editing in a model that can prove what happened to them.