Tech stack

KillerPDF is a native Windows app. There is no Electron, no browser engine, and no runtime to install. It relies on a small set of focused libraries, each handling one job:

Install, folders & data

KillerPDF is portable first - the single exe runs from anywhere with nothing to install. Installing is optional. A per-user install needs no administrator rights, while the all-users option requests elevation and installs under Program Files.

What the installer does

A per-user install copies the running exe to %LOCALAPPDATA%\Programs\KillerPDF\. An all-users install copies it to %ProgramFiles%\KillerPDF\ after a Windows elevation prompt. Both modes add Start Menu and optional desktop shortcuts, register the PDF handler and killerpdf: protocol at the matching user or machine scope, and create an Add/Remove Programs entry. Uninstalling removes the installed files, shortcuts, and registry entries.

Where things live

Everything sits under %LOCALAPPDATA% on purpose: it is per-user (no admin), user-private, and not indexed by Windows Search - so temporary copies of your documents never surface in search or another account.

Where OCR files go

OCR is bundled in the exe but unpacks on first use. The Tesseract native libraries extract to a per-version cache at %LOCALAPPDATA%\KillerPDF\ocr\<version>\x64\ (version-stamped, so an update gets fresh binaries). The language data lives in %LOCALAPPDATA%\KillerPDF\tessdata\: English ships inside the exe and is written there the first time you OCR, and any extra languages you pick are downloaded into that same folder. It is version-independent, so downloaded languages survive app updates. Both are read from these locations on every OCR run.

Temp files

Working files are written as killerpdf_<tag>_<guid>.pdf and tracked for the session. They are deleted when you close the app; anything a crash leaves behind is swept on the next launch (both the current Temp folder and the legacy %TEMP% location). Files still open in another instance are skipped and cleared later.

Clear all data

The Clear all Data link in the About window wipes everything KillerPDF has stored: the registry settings, the downloaded OCR languages and native cache, and the temp folder. It is best-effort - anything locked by the running session (a loaded native DLL, say) is skipped and clears on the next restart. Your actual PDFs are never touched.

Architecture

MainWindow is the application shell. It owns the shared toolbar, sidebar, dialogs and application-level workflows. Each document pane is a reusable PdfViewer control with its own view state, tab strip, render surfaces and document interaction code. Two viewer instances create split pane without opening a second window. Rendering, annotations, forms, links, crop, selection, text editing, tabs and zoom are divided across 16 Controls/Viewer/PdfViewer.* partials. Bridge files keep the remaining shell features connected while the refactor continues, and shared work lives under Services/ and feature controllers. In total the app is about 120 C# source files and 42,000 lines, not counting tests or the vendored PdfSharpCore fork under third_party/.

Two render pipelines

KillerPDF draws pages in two different ways depending on the view you are in. Single, Two-Page and Grid views draw into one main tile (RenderPage). Continuous scrolling uses a separate path (RenderContinuousPages) that streams page images in the background as you scroll. RenderPage is deliberately switched off during Continuous so the two systems never fight over the same tile.

Per-tab sessions & an LRU cache

Each open document is a DocumentSession that remembers its own zoom, fit and view mode, grid columns, current tool, page, and scroll position, along with its per-document data (annotations, page sizes, rotations, form values, and undo history). Switching tabs simply points the app back at that session. Each session also keeps a cache of already-drawn page images, so flipping back to a recent tab is instant and skips the renderer entirely. To keep memory in check, only the three most recently used tabs hold on to that cache.

Canvas & overlay maps

When KillerPDF displays a page, it stacks two things on top of each other: the page itself, drawn as a flat image, and a clear sheet sitting directly over it. That clear sheet is called an overlay, and it is where everything you add to a page (highlights, text boxes, drawn ink, signatures) is painted. The image underneath is never altered; your marks live on the overlay above it. A page's image-and-overlay pair is referred to as a tile.

The wrinkle is that KillerPDF has four ways of showing pages: one at a time, a continuous scroll through the whole document, a grid of pages, and two pages side by side. Each of those lays pages out differently, so each page you can see needs its own overlay in its own place. There is no single fixed sheet to draw on. Instead KillerPDF keeps a lookup table that takes a page number and hands back that page's current overlay. In the code this table is named _pages, and it is the one place the app trusts: every time it repaints a page's annotations, it asks this table which overlay to use and draws there.

A second table, _continuousCanvases, tracks the overlays for whichever multi-page layout happens to be on screen (the continuous scroll, the grid, or the two-page view). When KillerPDF builds a new overlay it registers it in both tables at once, through a helper named WirePageOverlay, so the two can never disagree about where a page lives.

One rule keeps the whole thing from breaking. The single-page style of layout is rebuilt by a routine that begins by throwing away the multi-page overlays. If that routine were allowed to run while the continuous scroll was showing, it would empty the lookup table, and every page would fall back to pointing at the hidden single-page tile. Your annotations would then be painted off-screen, out of sight, until you switched view modes. To prevent that, the routine is blocked from doing anything at all while the continuous scroll is active.

The coordinate space

KillerPDF keeps where a mark sits separate from how large it is drawn. The position is stored in a fixed internal measurement that never changes as you zoom, while the number of pixels actually drawn grows as you zoom in. Holding those two ideas apart is what lets an annotation stay locked to the same spot on the page while the page is always drawn sharply at whatever magnification you are using.

1. A fixed internal size ("render-dim")

Every page is first scaled to a standard internal size: the longer of its two sides is set to exactly 2048 units, and the shorter side is scaled to keep the page's proportions. These units are counted on their own and have nothing to do with screen pixels, so they do not change when you zoom or switch view modes. Annotation positions are recorded in this fixed measurement, which is why a mark stays in exactly the same place on the page no matter how far you zoom or which layout you view. The code calls this render-dim space, and the two resulting numbers, the page's width and height in these units, are written rdW and rdH below. One point, the unit the PDF itself uses, is 1/72 of an inch.

2. Drawing sharpness follows zoom, not position

The page image (the bitmap, meaning the grid of pixels the page is rendered into) is drawn at a resolution that follows two things: your display's pixel density and your current zoom. Magnify a page three times and it is redrawn from three times as many pixels rather than stretched, so text and lines stay sharp instead of turning blocky. A ceiling of 6144 pixels on the longest side limits how much memory a single page can take. This affects only sharpness; the stored positions from step 1 are untouched, which is the entire reason the two are kept apart.

3. The coordinate Y-flip

The final step is that the PDF format and the screen disagree about where a page begins. A PDF measures positions from the bottom-left corner and counts upward, while the screen, and KillerPDF's drawing surface, measures from the top-left corner and counts downward. So every mark has to be turned top-to-bottom as it is drawn, and scaled from the PDF's own points into render-dim units at the same time. In the formula below, pdfW and pdfH are the page's width and height in PDF points; renderW and renderH are the same page in render-dim units (the rdW and rdH from step 1); sx and sy are the scale factors between the two; left and top are the mark's position read from the PDF; and the result, canvasX and canvasY, is where the mark is placed on the drawing surface.

Because rdW and rdH are worked out once and then reused everywhere, the same measurements feed all four view modes, so a mark placed in one mode lands on the exact same spot in every other.

The annotation model

Every annotation lives in _annotations, a Dictionary<int, List<PageAnnotation>> keyed by page. Six types cover everything the toolbar can draw:

One funnel, every repaint

No commit path paints annotations directly - they all call RenderAllAnnotations(page), which clears that page's overlay, repaints every annotation in _annotations[page], re-adds the live form fields, then re-applies the search highlights last. That tail ordering is why a highlight survives every re-render, scroll and zoom instead of being painted over.

Undo

Edits push onto a single _undoStack. A linked pair (Cover + Text) goes on as one entry, so a single Ctrl+Z removes both halves together rather than leaving an orphaned cover behind.

Editing existing text

Double-click a line of real PDF text and KillerPDF reads the words underneath, then drops two linked annotations as a single undo: an opaque Cover that blocks the original, and an editable Text box on top. A shared PairId locks them together.

Zoom & interaction

Cursor-anchored zoom

Ctrl+wheel zooms around the cursor. The cursor position and scroll offsets are captured before the zoom changes, then the offsets that keep that point fixed are applied once layout settles:

Grid zoom by column count

Grid snaps to a whole number of columns: the count is authoritative and the zoom is derived from it, so the grid lays out exactly N pages with no leftover gap.

Saving & the temp-reload dance

Saving never changes the document you are looking at. KillerPDF writes a clean copy with no annotations, then permanently bakes in stamps first, then annotations, and reopens that fresh copy. Starting from a clean base every time means it can never accidentally bake the same thing in twice.

Why structural edits reload

Rotation, page operations and decryption route through SaveTempAndReload. It zeroes every page's /Rotate entry before writing, because Docnet (PDFium) sizes the page bitmap from the unrotated MediaBox - leave the rotation in and the rendered content clips. The file is written flat, reopened in Modify mode, and the rotations are re-applied in memory so the page still reads right.

Robustness

KillerPDF is built to open the PDFs other viewers choke on. It tries a normal open first, then catches each kind of failure and routes it to a specific recovery. Two rules hold throughout: heavy recovery work runs off the UI thread behind the busy overlay, and a repair never edits your file - it always produces a copy.

The open fallback ladder

The open path is a chain of typed exception handlers, each rung catching one class of failure:

Encryption is stripped at open

PdfSharpCore can read an encrypted PDF but cannot re-serialize a modified one - it would write back stale encrypted bytes and fail. So when a file is encrypted, the encryption is removed at open time (PDFium, lossless, with a PdfSharpCore Import fallback). That pass is CPU-heavy, so it runs on a background thread behind the busy overlay; every later edit and save then behaves like a normal document.

Network and partial reads

UNC shares and the WSL \\wsl$ 9P filesystem sometimes hand back partial reads, which the parser sees as a truncated file. Before opening anything on a network path, KillerPDF copies it to a local temp with a single read-to-EOF, then opens the complete copy - while keeping your original path for display and Save.

Repair works on a copy

When recovery falls through to a repair, the file is piped through PDFium, which has aggressive error recovery and rewrites a correct cross-reference table into a brand-new file. The original on disk is never touched. Repaired copies can lose bookmarks, forms and other interactive features, and the dialog says so before proceeding.

Standards conformance

A PDF editor has one obligation above all others: saving your file must not damage it. Starting with 1.6.4, that claim is tested rather than assumed. Every release is validated against veraPDF, the industry reference validator for PDF/A and PDF/UA, across a 2,907-file public conformance corpus (the veraPDF test corpus, the Isartor PDF/A-1b suite, and the TWG test files). These are deliberately hostile files, most built to violate exactly one clause of a standard, so any structural damage a save introduces shows up immediately as a newly failed rule.

How the test works

Every corpus file is validated pristine, resaved through KillerPDF's normal open/save pipeline (headlessly, via --batch-resave), and validated again. A comparison script then flags any file that fails a rule after the resave that it did not fail before. The bar for release is zero regressions. A second pass runs qpdf --check on every original/resave pair and flags any file whose structural health worsened.

The numbers (v1.7.0, veraPDF 1.30.2)

Patching the write engine at the source

Getting to zero meant fixing the write engine itself. PdfSharpCore is vendored into the repo and patched rather than worked around; each patch is marked in the source and documented with the ISO clause it satisfies:

• No Producer/Creator stamped into the Info dictionary of an imported document (PDF/A requires Info to stay equivalent to the XMP metadata).
• No /ModDate rewritten the moment a file is opened for modification (same rule).
• No transparency /Group injected onto every page (forbidden outright in PDF/A-1).
• Stream /Length always matches the spec's exact byte count, empty streams included.
• Booleans serialized as the PDF keywords true / false; the library wrote True, .NET's capitalization, which is not a valid PDF token at all.
• The debug-only "verbose" file layout removed, so no build can pad object tokens in ways the object-syntax rules forbid.

On top of that, every save scrubs the damage older libraries left behind: dangling outline references, degenerate crop boxes, and dead digital-signature values (a signature's digest must cover the whole file, so any edit invalidates it; leaving the stale value in place fails strict validation).

The one known limitation: PDF/A-4 is built on PDF 2.0, and the write engine serializes PDF 1.7, so the single PDF/A-4 corpus file picks up the version-marker rules on resave. That is a header limitation, not structural damage, and KillerPDF does not claim PDF/A-4 output.

The full report, the comparison script, and instructions for reproducing the run ship in the repo under validation/RESULTS.md.

Localization

Every visible string lives in a per-locale ResourceDictionary under Strings/ - ten locales, one XAML file each. Nothing hard-codes text; code and XAML resolve a key through Loc("Str_...") or a DynamicResource, so switching language reflows the whole UI live, no restart.

Captions and tooltips are separate strings

A toolbar button carries two independent strings: the hover tooltip (Str_TT_*) and the text caption under or beside the icon (Str_Lbl_*, mapped per glyph). Because they are localized separately, the toolbar can shed captions to save width while every tooltip stays intact.

Constants & limits

A full 47-page technical brochure (the same facts, with the interactive forms and theme gallery) ships in the repo as KillerPDF.pdf - open it in KillerPDF itself.

Glossary

Plain-language definitions of the terms and libraries used on this page, in alphabetical order.