DNPR — DOM-Native PDF Rendering | Patent-Pending Technology

“DNPR gives you control over your PDF — not just access to it.”

PDF as a Live Object

DNPR parses every element into a structured, queryable object tree. Click any node to expand.

report.pdf

Quarterly Report

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

See appendix A →

DNPR

DOM Object Tree

{
  "page": 1,
  "dimensions": { "w": 612, "h": 792 },
  "elements": [
    { // Heading
      "type": "text",
      "tag": "<span>",
      "content": "Quarterly Report",
      "style": {
        "fontFamily": "Helvetica-Bold",
        "fontSize": 24,
        "color": "#1a1a1a",
        "x": 72, "y": 720
      }
    },
    { // Paragraph
      "type": "text",
      "tag": "<span>",
      "content": "Lorem ipsum dolor...",
      "style": {
        "fontFamily": "Helvetica",
        "fontSize": 12,
        "color": "#333333",
        "lineHeight": 1.5
      }
    },
    { // Chart graphic
      "type": "graphic",
      "tag": "<svg>",
      "paths": [
        { "d": "M10,60 L40,30...", "stroke": "#E50914" }
      ]
      "attributes": {
        "width": 468,
        "height": 180,
        "x": 72, "y": 400
      }
    },
    { // Hyperlink
      "type": "annotation",
      "subtype": "Link",
      "content": "See appendix A",
      "attributes": {
        "href": "#appendix-a",
        "color": "#E50914"
      }
    }
  ]
}

Canvas vs. DNPR

Every online PDF editor today uses the same approach: rasterize the PDF to a <canvas> and bolt editing on top. DNPR replaces that entire model.

Canvas-based (PDF.js / PDFium)

Document as an image

PDF is rasterized to <canvas>.
Text overlay is a separate floating layer.
Two disconnected systems pretending to be one.
No native editing. No real control.

DNPR (Patent Pending)

Document as an object

PDF is parsed and mapped to real DOM nodes.
Text is <span>. Graphics are <svg>. Layout is CSS.
One unified, editable, queryable structure.
Full browser-native control.

Why It Matters

01

Up to 95% faster editing on large documents

Canvas-based editors require you to select a tool before every action — move, edit, style, choose font. DNPR eliminates this entirely. Text blocks are live DOM nodes: click and edit, like a web page.

Benchmark: 50 editing steps in PDF.js vs significantly fewer in DNPR on the same document.

↑ 95% editing speed on large docs

02

Graphics as controllable objects, not flat images

In Canvas-based rendering, images inside a PDF are pixels inside pixels — you can't select, move, or manipulate them without a dedicated tool layer on top.

In DNPR, every graphic element is an <svg> or image node in the DOM. Move it, resize it, delete it — using standard browser behavior.

03

AI-native core — documents AI can actually rebuild

Canvas gives AI a flat image. DNPR gives AI a structured object tree it can read, traverse, and modify programmatically — without quality loss, without guessing pixels.

Example: Change the entire color scheme of a document via a single API call.

~150ms API call vs hours of manual work

04

100% browser-local — zero server dependency

DNPR runs entirely in the browser. Your document never leaves your machine. No upload, no processing server, no network request required to render or edit a PDF.

The browser is the runtime. Privacy is the default.

Zero server requests on render

05

Native accessibility — screen readers just work

Canvas is invisible to accessibility tools. DNPR renders real text into real DOM — screen readers, keyboard navigation, and browser accessibility APIs work out of the box, with zero additional implementation.

How DNPR Works

Four stages transform a raw PDF binary into a fully editable, browser-native document.

Step 01

PDF 2.0 Parsing

A proprietary interpreter parses the PDF binary structure — extracting text streams, glyph positions, font metadata, vector graphics, and image objects from the raw file.

Step 02

DOM Mapping

Each PDF element is mapped to a native browser node. Text → <span> with CSS positioning. Vectors → <svg>. Images → <img>. Layout → CSS.

Step 03

Live DOM Tree

The result is a fully traversable, editable DOM tree. Every element is selectable, queryable, and manipulable using standard browser APIs — no abstraction layer needed.

Step 04

Native Browser Behavior

Text selection, cursor positioning, clipboard, undo/redo, accessibility — everything works through the browser's native mechanisms. No canvas. No hacks. No overlays.

Intellectual Property

US Patent Pending

METHOD AND SYSTEM FOR RENDERING PDF DOCUMENTS DIRECTLY TO DOCUMENT OBJECT MODEL WITH NATIVE INLINE EDITING

US Provisional Patent Application · Filed March 6, 2026
Inventor: Artsiom Kirkor · Micro Entity

Application No.

63/997,982

DOM-Native PDF Rendering