How We Built a Free Open-Source PDF Editor with Next.js

The Vision: Privacy-First PDF Editing

Most PDF editors today require you to upload your documents to their servers. For sensitive documents like contracts, medical records, or financial statements, this is a privacy nightmare.

We wanted to build something different:

• 100% client-side processing — files never leave your browser
• No installation required — works directly in web browsers
• No signup or tracking — completely anonymous usage
• Open source — transparent code anyone can audit
• Free forever — no paywalls or subscriptions

With these principles in mind, we started evaluating technologies that could make this vision a reality.

Choosing the Tech Stack

Frontend Framework: Next.js 14

We chose Next.js 14 with the new App Router for several reasons:

• Excellent SEO capabilities — server-side rendering and metadata management out of the box
• Static export support — deploy anywhere (Vercel, Netlify, GitHub Pages)
• TypeScript integration — type safety and better developer experience
• Performance optimization — automatic code splitting, image optimization
• Developer experience — hot reload, great documentation, huge ecosystem

PDF Rendering: PDF.js

PDF.js by Mozilla is the gold standard for rendering PDFs in the browser. It's what powers Firefox's built-in PDF viewer.

PDF Manipulation: pdf-lib

For creating and modifying PDFs, we use pdf-lib — a pure JavaScript library that runs entirely in the browser.

State Management: Zustand

Instead of Redux, we chose Zustand — a minimal, fast state management library.

• Simple API — no boilerplate code
• TypeScript-first design
• Small bundle size (~1KB)
• No context providers needed

Styling: Tailwind CSS

Tailwind CSS gives us utility-first styling with excellent developer experience and small production bundles through automatic purging.

Architecture & Design Decisions

1. Client-Side Processing Only

Everything happens in the browser:

User uploads PDF
  ↓
PDF.js parses and renders to canvas
  ↓
User makes edits (text, images, shapes)
  ↓
pdf-lib creates new PDF with changes
  ↓
Download to user's device

At no point does the file leave the user's device. This is true privacy by design.

2. Normalized Coordinate System

One major challenge: PDFs have different page sizes, and users can zoom in/out. How do we track overlay positions?

Solution: Normalize all coordinates to the range [0, 1].

// Instead of absolute pixels:
{ x: 150, y: 200 }

// We store normalized coordinates:
{ x: 0.25, y: 0.33 }

// Then scale to current viewport:
actualX = normalizedX * pageWidth * zoom
actualY = normalizedY * pageHeight * zoom

This makes overlays zoom-independent and portable across different page sizes.

3. Component Architecture

We structured the app into focused components:

• PdfViewer — main canvas rendering
• Thumbnails — page navigation sidebar
• Toolbar — zoom, rotate, delete controls
• EditToolbar — tool selection (text, image, shape)
• AdvancedOverlayLayer — text, images, shapes rendering
• ExportButton — PDF export logic

4. State Management Pattern

Our Zustand store maintains:

{
  originalFile: File,
  pages: [
    {
      id: string,
      originalIndex: number,
      rotation: 0 | 90 | 180 | 270,
      deleted: boolean,
      textOverlays: [],
      imageOverlays: [],
      shapeOverlays: []
    }
  ],
  selectedPageId: string,
  zoom: number,
  editMode: 'select' | 'text' | 'image' | 'shape'
}

Technical Challenges We Faced

Challenge 1: Text Extraction Accuracy

PDF.js can extract text, but positioning isn't always pixel-perfect due to how PDFs encode text (sometimes as individual characters, sometimes as words).

Solution: We extract text items with their transformation matrices and convert to normalized coordinates with generous bounding boxes.

Challenge 2: Performance with Large PDFs

Rendering 100+ page PDFs can freeze the browser.

Solution:

• Lazy load pages (only render visible pages)
• Use requestAnimationFrame for smooth rendering
• Recommend 25MB / 50 pages limit
• Offscreen canvas for thumbnails

Challenge 3: Export Quality

Embedding text and images in pdf-lib requires careful coordinate transformation from browser space to PDF space.

Solution: Build a comprehensive transformation pipeline that handles:

• Page rotations
• Coordinate system differences (Y-axis flipped in PDF)
• Font embedding and sizing
• Image format conversion

Challenge 4: Browser Compatibility

Different browsers have slightly different canvas implementations and PDF rendering quirks.

Solution: Extensive testing across Chrome, Firefox, Safari, and Edge. Use feature detection instead of browser detection.

Why We Made It Open Source

From day one, we knew this had to be open source:

The Results

After months of development, we launched EditoraPDF with:

The codebase is available at github.com/affsquadDevs/editorapdf under the MIT License.

Key Takeaways for Developers

Get Involved

EditoraPDF is an open-source project, and we welcome contributions from developers of all skill levels.

Frequently Asked Questions

Final Thoughts

Building EditoraPDF was a challenging but rewarding journey. We learned immense amounts about PDF processing, browser capabilities, and open-source development.

The best part? Anyone can now take this code, learn from it, modify it, or build something even better. That's the power of open source.

If you're working on a similar project or just curious about the code, check out the GitHub repository. We'd love to hear your feedback, answer questions, or review your pull requests.