Online PDF tools ask the user to upload the document. For a holiday itinerary that is unremarkable; for a contract, a payslip, a medical result or a scanned identity document it is a transfer of custody, and the privacy policy is the only thing standing between the file and whatever the operator chooses to do with it. EditPDF removes the transfer rather than promising to handle it well: forty-one PDF tools run inside the browser tab, the application is a static bundle with no backend, and the document never leaves the machine. This paper describes what that constraint costs and how the implementation pays it. Three problems dominate. First, the reading and writing of PDF must be split across two libraries with incompatible strengths — PDF.js can render and extract but not author, pdf-lib can author but not render — so the pipeline renders through one and writes through the other, with the page canvas serving as the bridge for operations that cannot be expressed structurally. Second, in-place text editing requires the glyphs of a font the browser may not possess and the document may only partially embed; the application ships metric-compatible substitutes for the three standard families and embeds them through fontkit, which keeps re-wrapped lines the right length at the cost of exact glyph fidelity when the original face is unavailable. Third, redaction cannot be done honestly by drawing a black rectangle, because the text survives underneath and remains extractable; the implementation instead rasterises each marked page so the words are destroyed, and states plainly in the interface that those pages stop being searchable. The paper argues that the third case is the clearest illustration of the project's stance: where a correct result and a convenient one diverge, the tool takes the correct one and tells the user what it cost.
The standard architecture for an online PDF tool is a file upload, a server-side operation, and a download link. It is simple to build and it works, and it also means that every document a user edits is, for some interval, resident on someone else's disk. The industry's answer to the resulting unease is the privacy policy: an assurance about conduct, verifiable by nobody, and irrelevant to an attacker who reaches the storage bucket by another route.
EditPDF, deployed at pdf.rominur.com, takes the other path. It is a static single-page application; opening a document hands it to the browser tab, not to a network. There is no upload endpoint, no processing queue, no temporary storage, and no retention window — not because these are well managed, but because they do not exist. The privacy property is structural rather than promissory, and a reader can confirm it from the network panel of their own browser.
The constraint is severe, and the rest of this paper is about the engineering it forces. Section 2 describes the split-library architecture. Section 3 covers in-place text editing and the font problem. Section 4 covers redaction. Section 5 surveys the tool set. Section 6 covers OCR and conversion. Section 7 states the limits.
No single JavaScript library both reads and writes PDF well, and the division is not arbitrary — it reflects what each was built for.
| Library | Used for | Cannot do |
|---|---|---|
| PDF.js | Rendering pages to canvas, text extraction, page geometry | Author or modify a document |
| pdf-lib | Structural edits: pages, annotations, form fields, drawing, metadata | Render a page; encrypt |
| @cantoo/pdf-lib | Password protection with granular permissions | — |
| fontkit | Embedding and subsetting TrueType faces for new text | — |
The application therefore maintains two views of the same document: a rendered view the user sees and interacts with, produced by PDF.js on a canvas with its worker configured to keep decoding off the main thread, and a structural view that receives edits and produces the saved file. Most tools are expressed structurally — splitting, merging, rotation, watermarks, page numbers, form fields — and never touch the canvas. A minority cannot be, and for those the rendered canvas becomes the source of truth: rasterised export to JPG and PNG at a chosen resolution, compression, and redaction as described in Section 4.
Encryption is the one place where the mainstream library was insufficient: pdf-lib upstream does not implement password protection, so the protect tool uses a maintained fork that does, setting user and owner passwords with a permission set in which printing is granted at high resolution or refused outright rather than silently downgraded.
A PDF records positioned glyphs, not paragraphs. Clicking a line and retyping it therefore requires reconstructing a structure the format never stored, and then rendering replacement text that matches what surrounds it. The second half of that problem is where browser-based editors usually fail visibly.
Replacement text must be drawn in a font. Three cases arise. If the document embeds the full face, it can be reused. If it embeds only a subset — the common case, since producers embed only the glyphs actually used — the characters the user newly types may not be present. If it embeds nothing and merely names a standard font, the file supplies no glyphs at all.
EditPDF handles the latter two by shipping metric-compatible substitutes for the three standard families and embedding them through fontkit when text is added or rewritten. Metric compatibility is the operative property: the substitute advances each character by the same width as the face it stands in for, so a rewritten line occupies the same horizontal space and the surrounding layout does not shift. The visual difference is a slightly different letterform; the alternative — substituting a font with different metrics — produces text that overflows its column or falls short of the margin, which is far more conspicuous. The fonts are bundled with the application rather than fetched, consistent with the no-network rule.
Alongside text editing sit the operations that do not require reconstruction at all: whiteout, which covers a region opaquely; inserted images, shapes and signature marks; and form filling, all of which are additive and therefore structurally straightforward.
Redaction is the operation most often implemented incorrectly, and the failure is well documented: a black rectangle drawn over a name changes only what is displayed. The text object beneath it is untouched, and any extraction tool — including copy and paste — returns it. Court filings and government releases have been de-redacted this way repeatedly.
Doing it correctly inside a browser is not a matter of a better drawing call. Removing a specific text run from a content stream while leaving the rest of the page intact is the kind of surgery Section 3 describes as difficult, and a partial job here fails dangerously rather than visibly.
EditPDF takes the blunt but sound route: a page carrying redaction marks is rendered to a canvas with the marked regions painted out, and that image replaces the page. The text is not hidden, it is gone — there is no text layer left to extract from. The application states the consequence in the tool itself rather than in a footnote:
A marked page is rebuilt as a picture. The words underneath are gone for good — not merely covered — so nothing can be selected, searched or copied back out. The price is that those pages stop being searchable.
This is the project's design stance in miniature. The rasterising approach is worse on every axis except the one that matters: file size grows, selectable text is lost, and only the marked pages are affected rather than the document as a whole. What it buys is that the redaction is real. Telling the user the price, at the moment of the decision, is the part most implementations omit.
Forty-one tools are grouped by intent rather than by implementation.
| Family | Tools |
|---|---|
| Edit & sign | PDF editor (in-place text, whiteout, images, shapes), fill & sign, create forms, watermark, page numbers, header & footer, Bates numbering, stamps |
| Organise | Merge, alternate & mix, split by range, in half, by size, by text, by bookmarks, extract pages, delete pages, organize, rotate, crop, resize, N-up, flip |
| Convert | PDF to Word, Excel, PowerPoint, text, JPG; JPG to PDF; extract images |
| Protect | Password protection with permissions, unlock, flatten, redact, remove annotations |
| Repair & refine | Compress, grayscale, OCR, repair, create bookmarks, edit properties, rename |
The taxonomy mirrors that of the author's desktop application, PdfRomeo, and the overlap is deliberate: the same operations are useful whether the user will install software or not. What differs is where the boundary of feasibility falls. The desktop application re-wraps a paragraph and shifts the content below it to make room, because it can measure with the document's own embedded metrics and rewrite the content stream in place; the browser application edits text within its existing box.
Scanned documents carry no text layer, and OCR runs in the tab through a WebAssembly build of Tesseract. This is the operation where the no-server rule is felt most directly: recognition speed depends entirely on the user's machine, and a long scanned document is measurably slower than it would be on a server. It is also the operation where the rule matters most, since scanned documents are disproportionately the sensitive ones — identity papers, statements, medical records — and these are exactly the files a user should be most reluctant to upload.
Conversion to Word, Excel and PowerPoint is performed by constructing the target format in the browser from extracted text and layout. The fidelity ceiling here is real and inherent: a PDF does not record which lines formed a table or which runs formed a heading, so a converter reconstructs that structure by inference. Simple documents convert well; heavily designed ones convert approximately.
The device is the computer. Everything runs in one tab, so a very large document is bounded by the memory the browser will grant it, and heavy operations are as fast as the user's machine and no faster. A server-backed competitor will beat it on a 500-page scan.
Redaction trades searchability for safety. Marked pages become images. This is the correct trade, and it is still a trade.
Conversion is inference. Output for complex layouts is an approximation, because the structure being recovered was never recorded.
Substituted fonts are not the original. Metric compatibility preserves the layout, not the letterforms. Where the document embeds no usable face, edited text will look close rather than identical.
No automation surface. With no backend there is no API and no batch queue; the tool serves a person at a keyboard, not a pipeline.
EditPDF is an argument that the upload in an online PDF tool is a convenience for the operator rather than a necessity for the user, and that removing it is affordable if the implementation absorbs the cost. Doing so forces a split-library pipeline, bundled metric-compatible fonts, and a redaction routine that destroys rather than conceals. The last of these is the most instructive: the honest implementation is worse in several measurable respects and correct in the one respect that matters, and the interface says so at the point of use. A privacy claim a user can verify in their own network panel is worth more than one they must take on faith.