DEV Community: nikoo li

Processing 100MB PDFs in the Browser: The Performance Optimizations That Made TinyPDF Usable

nikoo li — Tue, 28 Jul 2026 15:35:11 +0000

Processing 100MB PDFs in the Browser: The Performance Optimizations That Made TinyPDF Usable

When I built TinyPDF (https://tinypdf.cn/?utm_source=devto&utm_medium=blog&utm_campaign=performance_optimization&utm_content=devto_performance_2026-07-28), I had one hard rule: no backend.

Everything had to run in the browser. No file uploads, no servers, no costs. Just drag, drop, compress, download.

But when I tested the first version with a real portfolio—88MB, 45 pages, full of high-res images—it froze the tab for 12 seconds.

Here's what I changed to get that down to 2 seconds, without losing any features.

1. Use Web Workers for PDF Parsing (Don't Block the Main Thread)

The first mistake: I ran PDF.js parsing directly on the main thread.

// ❌ Bad: Blocks UI while parsing
const pdf = await pdfjsLib.getDocument(arrayBuffer).promise;

The fix: Offload everything to a Web Worker. The main thread only handles user input and progress updates.

// ✅ Good: Web Worker does the heavy lifting
// Main thread
const worker = new Worker('pdf-compressor.worker.js');
worker.postMessage({ type: 'process', data: arrayBuffer, targetSizeMB: 2 });
worker.onmessage = (e) => {
  if (e.data.type === 'progress') updateProgress(e.data.percent);
  if (e.data.type === 'done') downloadBlob(e.data.blob);
};

Result: Tab stays responsive even with 100MB files.

2. Stream Image Processing (Don't Load All Pages Into Memory)

Second mistake: I loaded every page into memory at once before processing.

For a 45-page portfolio, that's 45 full-res images in memory simultaneously.

The fix: Process one page at a time, and stream results to the output blob incrementally.

// ✅ Good: Process one page, free memory, repeat
for (let i = 1; i <= numPages; i++) {
  const page = await pdf.getPage(i);
  const viewport = page.getViewport({ scale: 1 });
  const canvas = document.createElement('canvas');
  canvas.width = viewport.width;
  canvas.height = viewport.height;

  // Render page to canvas
  await page.render({ canvasContext: canvas.getContext('2d'), viewport }).promise;

  // Compress and add to output
  const compressedImage = compressCanvas(canvas, currentQuality);
  addToOutputBlob(compressedImage);

  // Clean up immediately (critical for 100MB files)
  page.cleanup();
  canvas.width = 0;
  canvas.height = 0;

  updateProgress(i / numPages * 100);
}

Result: Memory usage stays flat even for 100-page documents.

3. Binary Search for Target Size (Avoid Wasted Cycles)

The core feature of TinyPDF is "compress to an exact target size in MB."

My first approach: Start at 100% quality, keep dropping by 10% until we hit the target.

That could mean 5-10 full passes over the document.

The fix: Binary search on quality.

// ✅ Good: Binary search finds optimal quality in ~5 steps
let minQuality = 0.1;
let maxQuality = 1.0;
let bestQuality = 1.0;
let bestSize = Infinity;

for (let attempt = 0; attempt < 5; attempt++) {
  const midQuality = (minQuality + maxQuality) / 2;
  const size = await estimateSizeAtQuality(midQuality);

  if (size <= targetSizeBytes) {
    // We're under target—see if we can go higher quality
    bestQuality = midQuality;
    bestSize = size;
    minQuality = midQuality;
  } else {
    // Over target—need to go lower
    maxQuality = midQuality;
  }
}

Result: Gets to optimal quality in 5 attempts, not 10+.

4. Early Termination for Impossible Targets

If a user asks to compress a 50MB document of pure text to 1MB, that's impossible—there's no image data to drop.

My first version would try anyway, wasting 30 seconds before failing.

The fix: Calculate a theoretical minimum size first.

// ✅ Good: Estimate minimum possible size before trying
const textVectorSize = await estimateTextVectorSize(pdf);
if (targetSizeBytes < textVectorSize * 0.9) {
  showWarning(`That target size might be too small—this document has ${(textVectorSize/1024/1024).toFixed(1)}MB of non-image content.`);
}

Result: User gets immediate feedback, no wasted processing.

The Result

100MB file: 12s → 2s
Tab stays responsive the whole time
Memory doesn't balloon
No backend, no uploads, no account needed

Try it: https://tinypdf.cn/?utm_source=devto&utm_medium=blog&utm_campaign=performance_optimization&utm_content=devto_performance_2026-07-28

What I Learned

Performance optimization isn't about "making it fast." It's about:

Not blocking the main thread (users notice freezes more than slowness)
Cleaning up immediately (memory is finite, especially on mobile)
Avoiding unnecessary work (binary search > linear search)
Setting expectations early (tell users when a target might be impossible)

What's the biggest performance win you've had in a browser-only app?

Building a PDF compressor in 2 weeks — no backend, no uploads, just browser magic

nikoo li — Sat, 25 Jul 2026 06:21:07 +0000

Stop Bloating Your GitHub Releases: Compress Project Docs to Exact Sizes

nikoo li — Wed, 22 Jul 2026 02:47:00 +0000

If you maintain an open-source project, you've probably hit this:

You generate a 40-page contributor guide with diagrams → 18MB
GitHub Releases has no hard limit, but clone times get slower for everyone
Some mirror sites do have limits
Your git clone gets slower over time as PDFs bloat the repo

I built TinyPDF for designers first, but I've been using it for my own project docs too: type the target size in MB, and it compresses to that size while preserving layout and readability as much as possible.

https://tinypdf.cn/?utm_source=devto&utm_medium=social&utm_campaign=opensource_docs&utm_content=devto_opensource_2026-07-22

No account, no watermarks, 100% free, works entirely in your browser (no server uploads).

Bonus: if you're using GitHub Actions, you could wire this into your release pipeline (the compression runs locally in-browser right now, but I'm thinking about a CLI version).

What's the biggest PDF you've committed to a repo? Let's compare in the comments.

Stop wasting time on PDF compression — one-click to your target size

nikoo li — Mon, 20 Jul 2026 15:47:33 +0000

Stop wasting time on PDF compression — one-click to your target size

Let's be honest: PDF compression shouldn't be a 15-minute task.

You export your document, drag it into a compressor, pick a "high/medium/low" preset, download, check the size… and it's still over the limit. Repeat. Adjust settings. Repeat again.

I built TinyPDF because this workflow was killing my productivity as a designer.

How it works (in 3 clicks)

Drop your PDF
Type your target size in MB (2MB, 5MB, 10MB — whatever you need)
Hit "Compress"

That's it. No guessing presets, no back-and-forth.

The tool automatically figures out how much to reduce image quality while preserving page count, page size, and layout. It keeps quality as high as possible while hitting your exact target.

Why this saves time

No trial and error: Set the size once, get it right first time
No account needed: Just open the page and compress
No ads, no watermarks: Clean, fast, distraction-free
Files stay local: Processing happens in your browser — no uploads to a server

Current limits (keeping it focused)

Desktop web only (mobile coming later)
One file at a time, up to 100MB
No batch mode yet

If you've ever found yourself wasting time on PDF compression, give it a try: TinyPDF

Would love to hear what workflows you'd automate next!

The overlooked PDF problem in upload forms: fixed file-size limits

nikoo li — Mon, 06 Jul 2026 02:16:20 +0000

A small product detail I keep running into: upload forms often fail PDFs for a very boring reason.

The file is not broken. The layout is fine. The user just needs the PDF to be under a fixed limit like 10 MB, 20 MB, or 25 MB.

This happens a lot with:

portfolio submissions
school or job applications
client handoff portals
internal forms
support ticket attachments

The usual advice is “compress the PDF,” but that is a bit vague. In practice, the user does not always want maximum compression. They want a specific outcome:

Make this PDF fit under the upload limit, then let me check whether it still looks acceptable.

That is the workflow I built TinyPDF around:

https://tinypdf.cn/?utm_source=devto&utm_medium=developer_promo&utm_campaign=portfolio_upload_limits&utm_content=devto_upload_limit_workflow_20260706

It is intentionally narrow:

Upload one PDF.
Enter the target size in MB.
Download the compressed result.
Open the result and inspect it before submitting.

The interesting product lesson for me is that “PDF compression” is too broad a category. The sharper use case is the moment when an upload form rejects a file and the user has one concrete number to hit.

If you build upload flows, what file-size limits do you usually set for PDFs? And do you explain the limit before or after the upload fails?

Compressing PDFs to a target file size instead of guessing quality presets

nikoo li — Thu, 02 Jul 2026 11:19:40 +0000

When a PDF is too large, the real requirement is often not “make it smaller.”

It is usually more concrete:

the job portal says the file must be under 10 MB
the school form rejects anything above 5 MB
the client upload system has a 20 MB limit
an email attachment fails at the last step

That is why I built TinyPDF as a small target-size PDF compressor:

https://tinypdf.cn/

Instead of choosing “low / medium / high” compression and checking the result manually, the workflow is:

Upload one PDF
Enter the target size in MB
Let the tool try to compress under that limit
Download the result

The implementation goal is to preserve page count, page dimensions, and layout whenever possible. If the PDF is image-heavy and the target is very small, there is always a quality tradeoff, so the UI tries to keep that expectation clear.

This is a narrow tool by design. It does not merge, split, edit, OCR, or sign PDFs. It only focuses on one annoying workflow: “this file needs to be under a specific size.”

I am sharing it here because I would like feedback from people who deal with document uploads in real workflows:

Is target-size compression clearer than quality presets?
What file limits do you see most often?
What privacy details should be visible before upload?