Patent Pending USPTO #63/997,982 — Filed March 6, 2026

DOM-Native PDF Rendering

The entire online PDF editing industry renders PDFs to Canvas — a frozen pixel buffer with no editing capability. We invented a different approach.

Patent-pending DNPR technology.

0%
of online PDF editors use PDF.js or pdfium under the hood

PDF.js (Mozilla) and pdfium (Google/Chromium) are the two libraries that power virtually every online PDF service you've ever used. They're excellent at what they were built for: viewing PDFs.

But here's the problem: they were never designed for editing.

The Canvas Rendering Problem

Both PDF.js and pdfium follow the same rendering approach. They read the PDF binary stream, interpret it, and paint pixels onto an HTML Canvas element. The result is an image — a flat, non-interactive picture of your document.

i
Good to know

HTML Canvas wasn't even designed for PDFs. It was created by Apple in 2004 for macOS Dashboard widgets. PDF.js and pdfium adopted it because PDF drawing commands happen to map neatly to Canvas methods — both are immediate-mode 2D drawing systems. But that mapping only works for rendering. Once pixels are painted, the document structure is gone.

Industry Standard Pipeline
PDF Binary
Structured stream
Canvas Parser
PDF.js / pdfium
Canvas
Pixel rasterization
Pixel Image
Flat, non-interactive
×
Dead end
Structure is lost — the output is pixels, just like a screenshot

Canvas is fundamentally a pixel-based drawing surface. Once the PDF is rendered to canvas, it's no different from a screenshot. There's no text you can select natively. No elements you can click. No structure you can manipulate. It's pixels all the way down.

The Addon Layer Problem

So how do existing services offer editing? They build additional layers on top of the canvas. Text overlay layers synchronized with coordinates. Input fields positioned over the canvas image. Custom font matching. Mode switches between "view" and "edit".

How Online Editors Actually Work
PDF Binary
Structured stream
Canvas Parser
PDF.js / pdfium
Canvas
Pixels only
Editing Addons
Layers bolted on top
UI
Heavy, mode-based
Extra architectural layer to emulate what the engine can't provide

This is why every online PDF editor feels heavy. Layer over layer. Mode switching. Limited graphic control. You're never actually editing the PDF — you're editing an approximation built on top of a picture of it.

The engine can extract text content and styles, but it cannot represent the PDF stream as DOM elements. That fundamental limitation cascades into every interaction.

The PDFox V2 Approach

PDFox V2 is powered by DNPR — a proprietary PDF 2.0 interpreter (patent pending) built on the latest PDF standard. Instead of painting pixels to a canvas, it reads the PDF binary stream and directly represents it as editable HTML DOM elements.

PDFox V2 Pipeline

From binary to editable DOM — zero addon layers

PDF Binary
Structured stream
Input
DOM Interpreter
Proprietary acceleration
DNPR Engine
DOM Renderer
Editable DOM + SVG
Triple Output
Editable UI
Click anywhere, type
Zero Lag
No addon layer — rendering and editing are the same system

Your PDF becomes a live, editable document — not a picture of one. Text you can click and type. Graphics you can select, move, and resize. Images you can reposition. Every element is individually addressable, supporting deletion, replacement, and repositioning.

The approach is formally designated DOM-Native PDF Rendering (DNPR) and is the subject of U.S. Provisional Patent Application #63/997,982, filed March 6, 2026. Unlike PDF.js or pdfium — which implement older PDF specifications — the DNPR engine is built on the latest PDF 2.0 standard with full compliance. That means native support for enterprise-grade encryption, digital signatures, and full accessibility support.

What DNPR Delivers

Powered by DNPR — proprietary PDF 2.0 interpreter (patent pending). A purpose-built engine, not a wrapper around existing libraries:

All of this runs entirely in your browser — a privacy-first, serverless architecture where no document data, page content, font binary, or user edit is transmitted to any remote server at any point during the document lifecycle.

No overlay layers. No mode switching. No addons. When you open a PDF in PDFox V2, you get a document you can edit like a Google Doc — because the rendering model was designed for it from day one.

What This Means for You

Canvas-Based Editors

  • Mode switching between view and edit
  • Text editing in separate input overlays
  • No direct graphic manipulation
  • Layer synchronization lag
  • Limited font fidelity in edit mode
  • Heavy, complex UI to compensate

PDFox V2 (DOM Engine)

  • Click anywhere and start typing
  • Native text selection and editing
  • Full SVG path and image control
  • Zero rendering-to-editing gap
  • Embedded fonts rendered natively
  • Clean, minimal interface

DOM-Native Rendering vs Canvas

PDFox (DOM) Everyone Else (Canvas)
Text selection Native, browser-level Simulated overlay, often misaligned
Accessibility Screen readers work out of the box Requires separate text layer hacks
Search Cmd+F just works Depends on extra implementation
CSS styling Full control over rendered elements None — it's pixels on a bitmap
Large documents Renders what you see, DOM-efficient Full page rasterization per viewport
Privacy Nothing leaves your machine Architecture limits local capabilities
Inline editing Native contenteditable — browser handles cursor, IME, clipboard Requires custom text input subsystem from scratch
Zoom quality Zero-cost CSS transform: scale() — infinite resolution Must re-render at each zoom level
Object-level control Select, delete, resize, reposition any element Architecturally impossible — pixel buffer is opaque
Offline support Full offline operation after initial page load Requires server for processing

Google Docs-Like Editing

Open any PDF and edit it directly. No tools to select, no modes to switch. Click and type. That's it.

Full Graphic Control

SVG paths, vector graphics, and images are DOM elements you can select, move, resize, and modify directly.

PDF 2.0 Native

Built on the latest PDF 2.0 standard. Enterprise-grade encryption, digital signatures, and archival compliance — not retrofitted, native.

Privacy by Design

There's no upload step to skip or toggle. Your PDF physically cannot leave your device because the entire processing pipeline runs in-browser. GDPR compliance isn't a checkbox — it's the architecture.

It Just Works

Text selection, find-on-page, copy-paste, accessibility — these aren't features built on top of a canvas hack. They come free because the content is real DOM.

No Installs, No Plugins

Open PDFox in your browser. Drop a file. Edit. Done. Works on any modern desktop browser — Chrome, Firefox, Edge, Safari.

Explore V2

Dive deeper into the engine, architecture, and features behind PDFox V2.

The Engine

Powered by DNPR — proprietary PDF 2.0 interpreter (patent pending). Full PDF 2.0 compliance with proprietary acceleration.

Learn more →

Architecture

Modular design with triple-output rendering (DOM + Canvas + SVG).

Learn more →

V2 Features

Toolless editing, graphic control, PDF/A compliance, digital signatures, accessibility, and more.

Learn more →

Tech Stack

The proprietary technology powering DNPR and PDFox V2.

Learn more →

Privacy-First by Architecture, Not by Policy

All PDF processing executes exclusively within the user's browser. No document data, page content, font binary, or user edit is transmitted to any remote server at any point during the document lifecycle.

PDFox is deployable as a fully serverless application: static assets served from any CDN, requiring no application server, no database, and no network connectivity after initial delivery. Offline operation is supported in full.

The browser itself is the sole processing and storage environment for your document.

Experience the Current PDFox

Your first document is free. After that, full access is €2.99 for 24 hours — no subscriptions, no recurring charges, no account required.

Try Free