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:

KillerPDF 1.9 renders pages, extracts text, searches and selects through The KillerPDF.Engine, which replaced PDFium, Docnet.Core and PdfPig. Rendering runs off the UI thread with viewport priority, cancellation and zoom refinement, and Tesseract remains available as an OCR fallback. The developer guide documents the engine APIs.

Install, folders & data

KillerPDF checks GitHub for newer stable versions at startup by default and asks before installing an update. Always check on startup in the confirmation dialog shares the About setting and saves your choice even if you decline the update. There is no separate background service.

At the bottom of the shortcut list, you can turn off all application keyboard shortcuts. Ctrl+Shift+K always works to turn them on or off, even when the others are disabled.

Ctrl+R rotates selected pages 90° clockwise. Ctrl+Shift+R rotates them 90° counterclockwise.

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

Portable copies store settings, saved signatures and OCR models in KillerPDF-Data beside the launcher. Native OCR libraries and temporary working files still use %LOCALAPPDATA%\KillerPDF.

Where OCR files go

All OCR language models, including English, download on first use and remain cached. Native Tesseract libraries extract to the versioned OCR cache.

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

Clear all Data removes saved settings, OCR models and temporary files where possible. Locked files may remain. Installed copies keep saved signatures and logs; portable copies also remove the KillerPDF-Data folder. Your source PDFs are not deleted.

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.

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.

Since 1.9 the drawing itself happens on a background thread. Pages in the viewport are rendered first, work for pages that have scrolled away is canceled, and a zoomed page shows a scaled image at once and is redrawn sharp when the wheel rests. The app and engine ship precompiled, installed fonts are cached, and font discovery runs in the background, so startup does not wait on it.

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

Since 1.9, editing a line of a PDF's own text changes the page itself. Choose the Text tool and double-click a line: KillerPDF reads the words under the click and opens an editor over them. When you commit, the old glyphs leave the page's content stream and the new text is written in their place. Nothing is laid on top of the page, so the result reads, searches, copies and prints as ordinary text in any PDF viewer.

Finding the line

KillerPDF works out the line the way a reader sees it. It takes the word you clicked, or the nearest word when the click lands between words, and follows that word's reading direction, so turned text is edited along its own baseline. It gathers the words on that line and stops at a wide horizontal gap, so a click in one column never pulls in the column beside it. A run of dots or underscores, which is how a flattened form draws an empty entry, is treated as an empty field instead of being merged into its label. The line's box is then converted from screen units to unrotated page points and handed to the engine.

Checking before touching anything

Before the editor opens, the engine walks the page's content stream without changing it and collects every glyph whose center sits inside that box. That pass answers one question: can this line be rewritten? There are four named reasons it cannot. The area holds no readable text, the text is drawn invisibly (render modes 3 and 7, which is how OCR lays its searchable layer over a scanned image), the text has a zero font size, or its font cannot be decoded. Only those cases fall back to a cover, described at the end of this section.

Rewriting the content stream

When you commit, only what you changed is sent: the new words, plus any size, color, letter spacing, typeface, underline or strikethrough that differs from the line as it was found. The engine removes the old glyphs from the content stream and writes the new text right after the text-showing operator that held the first of them, inside the same text object. Because it sits in the same place in the stream, the new text inherits everything the old text was drawn with: font, size, color, clipping and stacking order. After the new text, the engine restores the text state and moves the text position back to exactly where the original operator left it, so everything drawn later in that text object stays where it was.

Sizes and spacing are given in points, but a PDF can scale its text through the text matrix and the page transform, so the engine converts them through the line's own transformation before writing them. Underline and strikethrough are drawn as thin lines just after the text object closes, because a path cannot be drawn inside one. The page gets a new compressed content stream wrapped in a saved and restored graphics state, and the change is written as an incremental update.

Which font the new text uses

KillerPDF keeps the original font whenever it can show the new text. An embedded font usually carries only a subset of its glyphs, the ones the document actually draws, so the engine uses only character codes that are already drawn in that font. It checks the edited page first and then the rest of the document. A font that is not embedded is supplied by the reader's own copy, so any code it maps with a width will do. A space the font cannot show becomes a gap of the same width.

When the original font cannot show a character you typed, or you pick a different typeface, the line is written in an installed Windows font instead. KillerPDF embeds only the glyphs it uses, as a Type 0 font with a ToUnicode map so the text still searches and copies correctly, and it respects the font's embedding permissions. The status bar says which font the line ended up in. Vertical text can only be rewritten in its original font.

Paragraph editing

Paragraph editing (Alt+Shift+P, the right-click menu, or the paragraph button on the text bar) rewraps a whole block of text inside a resizable box, with its own font size, alignment and line spacing. It is deliberately conservative. A paragraph qualifies only when its lines start at the same left edge, sit an even distance apart, use one font at one size, read left to right and belong to one text object. Encrypted, signed, certified, tagged and rotated documents are refused, as are pages with clipping, special graphics states, reusable form content or marked content, and KillerPDF says which rule stopped it.

The new text is wrapped with the replacement font's real glyph widths. Before you can apply it, KillerPDF lays the result out in a scratch document and measures the actual ink of every glyph, so an italic overhang that crosses the box edge is caught instead of clipped. The preview is the exact document Apply returns, and KillerPDF checks that the file has not changed since the dialog opened before it applies anything. This first version covers Latin text and ordinary typographic punctuation, because combining marks and right-to-left scripts need a shaping engine it does not have yet.

Find and Replace

Find and Replace runs the same rewrite on every matching line, in one pass and as one undo. Lines on scanned pages fall back to covers, and text you placed yourself as an annotation is changed in place. Text already hidden by an earlier cover is skipped, because what the reader sees there is the replacement, not the original. Turned text is left alone, and the result counts it so nothing is skipped silently.

Undo for page edits

A rewrite changes the document rather than adding an annotation, so its undo works at the document level. Just before the edit, KillerPDF captures the working file, and once the rewrite and reload succeed, that copy goes on the undo stack. Ctrl+Z restores it in one step. A failed rewrite pushes nothing, so it never leaves a phantom entry behind.

When KillerPDF falls back to a cover

The cover method from earlier versions remains for text the page does not really draw: the recognized layer over a scan, fonts that cannot be decoded, and image-only pages, which have no text layer at all. There KillerPDF drops two linked annotations as a single undo: an opaque Cover that hides the original, and an editable Text box on top. A shared PairId locks them together, and the status bar says the edit is a cover.

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

A structural edit (inserting, deleting or reordering pages, a Transform, a text rewrite) is not applied to the document in memory. KillerPDF writes a temporary PDF through The KillerPDF.Engine, reopens it, and restores page rotations and pending annotations as needed, so what you see is always a file the engine has parsed back rather than an in-memory guess. That working copy lives in %LOCALAPPDATA%\KillerPDF\Temp, and is swept when the app closes. Just before a text rewrite, Undo captures that working copy so Ctrl+Z can restore it in one step. Your original file changes only when you save.

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.

The engine also encrypts a whole document as a rewrite, either with AES-256 passwords and permissions or for certificate recipients, and the desktop app opens certificate-encrypted files with a matching certificate from the Windows store.

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 a file cannot be opened even read-only, KillerPDF asks before attempting a repair, and the repair produces a copy: the engine rebuilds the cross-reference table and recovers what it can of the page tree into a fresh file, and the status line says you are looking at a repaired copy that needs Save to keep. The original on disk is never written. The dialog warns beforehand that a repaired copy can lose bookmarks, forms and other interactive features, and a repair that had to rasterize the pages says text is no longer selectable. Merge, Split and Extract read damaged files that open in the viewer, and a save that repaired broken references says so without claiming the missing content was recovered.

Standards conformance

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.

Historical standards validation

Documented 1.8.1 standards run, August 29, 2026. See the validation report for the method and full results.

Owning the document engine

KillerPDF 1.8 replaced its legacy PdfSharpCore write pipeline with The KillerPDF.Engine, built in this repository from PDF syntax upward, and 1.9 moved rendering, text extraction, search and selection onto the same engine, retiring PDFium, Docnet.Core and PdfPig. 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/: 20 locales, one XAML file each, including Vietnamese, Russian, Kazakh, Italian, Polish, Hungarian, Bengali, Japanese, Ukrainian, Norwegian Bokmål, Brazilian Portuguese, 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

The 50-page guide includes the current shortcuts, all themes and languages, and an interactive sample form. It 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.