Tech stack

KillerPDF is a native Windows application built on modern .NET. There is no Electron and no browser engine. The installed edition uses the .NET 10 Desktop Runtime; the portable edition carries its own runtime. Each major subsystem has a deliberately narrow job:

Install, folders & data

KillerPDF ships in two forms. The compact installer is the standard download and supports per-user or all-users installation. The larger portable edition contains its own runtime and runs from anywhere without installation.

What the installer does

The installer verifies and extracts the framework-dependent application to %LOCALAPPDATA%\Programs\KillerPDF\, or to %ProgramFiles%\KillerPDF\ after an elevation prompt for all users. Installed shortcuts launch KillerPDF.App.exe directly. The portable edition verifies and extracts its self-contained payload for the current run. Installed copies register the PDF handler and killerpdf: protocol at the matching scope and create an Add/Remove Programs entry.

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 a composed application shell rather than one giant code-behind. Its partials under Shell/ own the shared toolbar, sidebar, dialogs and application workflows, while each document pane is a reusable PdfViewer with independent tabs, view state, render surfaces, thumbnails and interaction state. Two viewer instances create split pane without opening a second window. Thin host adapters connect the shell and viewers; reusable application policy lives under Services/; focused controllers live under Features/; and all PDF structure and serialization crosses the independent KillerPDF.Engine boundary.

Source size

As measured from the current 1.8.2 development tree, KillerPDF contains 418 C# files and 139,519 physical source lines. Production code accounts for 314 files and 100,609 lines: 155 application files (49,711 lines), 151 engine-library files (47,792 lines), two corpus-runner files (2,200 lines), and six packaging files (906 lines). The remaining 104 files and 38,910 lines are application and engine tests. Generated build output is excluded.

Two render pipelines

KillerPDF has a primary-page renderer (RenderPage) and a multi-page streaming renderer used by Continuous, Grid and Two-Page layouts. Single view uses the primary tile; multi-page layouts create per-page tiles and replace their bitmaps progressively as work completes. RenderPage is deliberately switched off during Continuous so a primary-page repaint cannot clear the live multi-page overlay map.

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 bounded, only the three most recently used tabs retain caches; each tab has an approximately 160 MB budget, keeps at least six useful pages where possible, and has a hard cap of 48 cached entries.

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 and permissions

The KillerPDF.Engine authenticates Standard Security revisions 2 through 6, including RC4, AES-128, AES-256 and crypt filters. It distinguishes user and owner authentication, exposes the document's operation permissions, and enforces those permissions at the high-level editing APIs. Authenticated documents can be updated incrementally or rewritten while preserving encryption; decryption is an explicit workflow rather than a prerequisite for every edit.

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 1.8 validation gates

Owning the document engine

KillerPDF 1.8 replaces its legacy PdfSharpCore document pipeline with The KillerPDF.Engine, built in this repository from PDF syntax upward. Validation is performed at parser, object-graph, writer, application-integration and public-corpus levels. The engine can preserve existing bytes through incremental revisions or produce deterministic full rewrites, and it fails closed when required structure cannot be interpreted safely.

• PDF 2.0 headers, cross-reference streams, object streams and incremental revisions are native concepts.
• PDF/A-4, PDF/A-4e, PDF/A-4f and PDF/UA-2 authoring safeguards are coordinated across metadata, fonts, structure, forms, annotations and associated files.
• Full rewrites are deterministic; incremental edits preserve the original byte prefix.
• Bounded parsing, graph validation and explicit implementation limits reject ambiguous or unsafe input before writing.

The complete reusable-library architecture, capability map, validation model and developer quick start are in the KillerPDF.Engine developer guide.

Localization

The desktop interface is localized through per-locale ResourceDictionary files under Strings/: 15 locales, one XAML file each, including Russian, Kazakh, Italian, Polish, Hungarian, Bengali, Japanese, and simplified and traditional Chinese. Code-built and XAML controls resolve keys through Loc("Str_...") or a DynamicResource, so switching language reflows the UI live without a 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 50-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.