Coder Legion - Recent posts tagged webassembly

I Built a Browser-Based GIF Compressor That Keeps Your Files on Your Device

Fri, 30 Oct 2026 09:51:36 +0000

Animated GIFs are easy to share, but their file sizes can get out of hand quickly. A few seconds of animation may be too large for a chat message, a community post, or a website. The usual fix is to upload the file to an online converter, wait for a server to process it, and download the result. I wanted a simpler workflow that does not require sending the original GIF to a server.

That is why I built GIF Compressor (https://gifcompressor.cc/), a free tool that processes animated GIFs locally in the browser.

What it does

You can drag in a GIF, choose a compression preset, and compare the original and compressed file sizes before downloading. The presets favor image quality, a balance between quality and size, or the smallest file. If you need more control, you can adjust compression strength, image dimensions, palette colors, and optimization level.

The tool also supports batches of up to 20 GIFs, with a 100 MB limit per file. The same settings can be applied across a batch, which is useful when preparing reaction GIFs, documentation assets, or animations for a website.

For specific upload limits, I added pages that attempt to reduce a GIF toward 10 MB or 1 MB. These use progressively stronger settings and show whether the target was actually reached; no compression tool can guarantee a particular size for every source GIF without potentially unacceptable quality loss.

Why browser-side processing?

The compression engine runs through WebAssembly in your browser. The GIF stays on your device while it is processed. Besides the privacy benefit, this removes the upload-and-wait step, especially noticeable for larger files or slower connections.

There is still a trade-off: GIF compression is not magic. Reducing colors or dimensions can make a file much smaller, but it can also change how the animation looks. I recommend starting with the quality-focused preset, previewing the result, and only increasing compression when the file is still too large.

Try it

GIF Compressor is available at https://gifcompressor.cc/. It is free to use, and there is no account needed for the compression workflow. I would appreciate feedback from other developers and creators: which GIF-size limits or batch workflows are most frustrating for you today?

RetroPlay: a browser hub for classic games, running entirely on WebAssembly

Wed, 09 Sep 2026 11:31:37 +0000

I've been putting together a side project for the last while and finally feel okay showing it around properly: RetroPlay, a browser hub for old-school games that all run through WebAssembly. No installers, no accounts, no "download our launcher first" — you open a page and you're already playing.

Repo: https://github.com/MahanKenway/RetroPlay Live: https://mahankenway.github.io/RetroPlay/

How it actually started

It began as basically a Doom WAD launcher one of those "let's see if I can get Doom running in a browser tab" weekend experiments that a lot of people have tried at some point. Mine actually worked well enough that I didn't stop after the weekend. I kept poking at it, then kept adding to it, and at some point it quietly stopped being "a Doom thing" and turned into something bigger: a small curated collection of separate game runtimes sitting behind one shared hub.

Every one of those runtimes is its own beast. Different engine, different save system, different input model, different everything under the hood. They just happen to live under the same roof and share the same visual shell, so from the outside it feels like one coherent product instead of eight unrelated experiments duct-taped together.

What's actually playable right now

This is the part I care about the most, honestly, because I got tired of retro gaming sites that advertise ten consoles and a thousand games and then, the second you click play, ask you to upload a ROM file you obviously don't own and never will. That model always felt dishonest to me. So the rule I set for RetroPlay from day one was simple: if a game is marked "Ready" in the catalog, it comes bundled with free, legally distributable content, and it just runs. No uploads, no accounts, no asking the player to go find something sketchy on the internet first.

Here's what's actually sitting in the Ready column right now:

Doom / Freedoom catalog — the original launcher that started this whole thing, still very much alive and still the entry point for a lot of people
C-Dogs SDL — a top-down run-and-gun that's more fun than it has any right to be for something this old-school
GNU FreeDink — the weird little action-adventure title that basically nobody remembers exists anymore, which is exactly why I wanted it in there
OpenTyrian2000 — a vertical shooter that scratches a very specific itch if you grew up on that genre
LibreQuake — a Quake-style first-person shooter running entirely on free data, no Quake WAD required
OpenTTD — and yes, this means the full transport strategy experience, timetables and all, sitting in a browser tab
FreeRCT — theme-park building in the classic RollerCoaster Tycoon spirit, without touching any actual RCT assets
Neverball — 3D ball-rolling physics puzzles, and I want to stress this is real gameplay captured from the actual runtime, not some rendered concept screenshot pretending to be gameplay
On top of that there are two entries I deliberately left visible instead of quietly hiding, because I'd rather be upfront about what's finished and what isn't. ECWolf is there as an engine-only host — it plays Wolfenstein-3D-engine games, but you have to point it at your own legally-owned game data, so it's not a one-click bundled experience. OpenResident is even more of a side experiment than that: it's basically a "can WebGL2 and WebAssembly actually handle something in this ballpark" technical probe, not a playable Resident Evil game, because the upstream engine it's built on doesn't ship with any actual game data to run. I could've just deleted both from the catalog to make the project look more polished, but that felt dishonest too.

Why WebAssembly, and why this isn't "just another emulator site"

Most of what's in RetroPlay isn't emulated in the classic ROM-emulator sense at all. These are the actual open-source game engines C-Dogs, FreeDink, OpenTTD, Neverball, and the rest — compiled with Emscripten directly to WebAssembly and dropped straight into the browser. That's a meaningfully different thing from running a ROM through an emulator core, and it's the whole reason licensing ended up being such a big part of how this project is structured. I only bring in engines and asset packs that are genuinely free to redistribute, whether that's Freedoom, OpenGFX/OpenSFX/OpenMSX for OpenTTD, or the clean-room content that ships with FreeRCT. Nothing commercial gets repackaged or smuggled in anywhere, on purpose.

How it's actually built, for anyone who cares about that side of it

The hub itself is intentionally boring on the frontend side plain HTML, CSS and ES modules, no framework doing anything clever. Each game runtime lives on its own separate page and loads its own WASM build independently, so nothing steps on anything else's dependencies or global state. That separation was a deliberate choice; it made adding new runtimes way less risky than if everything shared one big bundle.

On the infrastructure side, GitHub Actions handles the whole pipeline: it installs a pinned Emscripten SDK, compiles every engine module, copies the static frontend into a dist/ folder, and ships the finished artifact to GitHub Pages. There's no backend server involved at any point — this is a static site from top to bottom, which also means hosting costs are basically zero and there's nothing to keep patched or worry about going down.

If you want to poke around locally without doing a full rebuild, it's genuinely just:

git clone https://github.com/MahanKenway/RetroPlay.git
cd RetroPlay
python3 -m http.server 4180 --directory dist
That spins up an already-built artifact. Actually rebuilding the engines from source is a bit more involved — you need a pinned Emscripten toolchain plus the per-game build scripts that live in scripts/, run in the same order CI uses so you're testing what actually ships.

Where this is going next

I'm slowly adding more free-content runtimes whenever I come across an open-source engine that feels like it deserves a slot — I'm not trying to rush this into being some giant catalog overnight, quality and licensing sanity matter more to me than raw numbers. Touch controls are also an ongoing project on my end, because I want the mobile experience to actually feel good and playable, not just technically function if you squint at it on a small screen.

If anyone here has built something similar, or knows of an open-source engine with genuinely free redistributable content that you think deserves a spot in the catalog, I'd honestly love to hear about it in the comments. That's a big part of why I'm posting this here instead of just letting it sit quietly in the repo where nobody stumbles across it.

To be clear about the intent: this is a non-commercial, preservation-minded project. Nothing here is being sold, there's no paywall, no ads shoved in your face, no account wall. It's just old games and classic engines staying playable in a normal browser tab without a ton of friction getting in the way.

When WebAssembly Is Worth The Build Step In A Web Game

Mon, 31 Aug 2026 11:53:33 +0000

Most of the wasm material floating around is about the toolchain: install Emscripten, pass these flags, ship the .wasm. The decision that comes before it gets far less attention, and for this crowd it is the more interesting one, so here is the version I would have wanted to read first.

What A Module Actually Is

WebAssembly is a binary instruction format, not a language you write. You compile C, C++ or Rust into a .wasm file, the browser validates it and turns it into real machine code, and that compile step is where the speed comes from. There is no warm-up period while a JIT works out which functions are hot, so a wasm function runs at full speed from its first call.

What surprises people is how little a module can do on its own. It has no DOM, no canvas, no network, no audio. It gets a block of linear memory, a set of exported functions JavaScript can call, and a set of imported functions JavaScript hands to it. Everything it does to the outside world crosses that boundary. Sandbox with a bridge is the mental model, and nearly every wasm performance surprise traces back to it.

The Boundary Is The Whole Design

Calling into a wasm function is fast. It is not free. Cross the boundary a few thousand times a frame with tiny calls and you can spend the entire advantage you compiled for.

The pattern that works is a coarse boundary. Pass data in batches, do as much work as possible inside the module before returning, and share state through linear memory instead of copying values back and forth. Rather than asking the module for each entity's position one call at a time, let it write every position into a shared buffer and read the whole buffer once on the JavaScript side.

This is also why a wasm rewrite of ordinary game logic often benchmarks slower than the JavaScript it replaced. The logic got faster and the plumbing got more expensive, and the plumbing won.

Two Toolchains Cover Almost Everything

For C and C++ it is Emscripten, which does much more than emit a binary. It ships a C library, maps OpenGL onto WebGL, simulates a filesystem, and generates the glue that loads the module and wires it to the page. Point it at an existing SDL or OpenGL game and with the right flags you get something playable without rewriting the source.

For Rust the support lives in the language ecosystem. wasm32-unknown-unknown is a first-class target, wasm-bindgen generates bindings with real types instead of raw numbers, and macroquad or Bevy sit on top depending on how ambitious the project is. Rust is what most people reach for when they are starting fresh rather than porting.

C#, Go and AssemblyScript all target wasm too, but for games those two paths have the deepest ecosystems and the most shipped titles behind them.

Your Engine Already Made This Choice

If you export from Unity or Godot, you are already shipping wasm. Both compile their C++ runtime to a module and drive a WebGL canvas from it, which explains the complaint everyone has: a trivial Unity web build is many megabytes because the engine runtime is the download, not your game. The load time you see is the browser compiling that binary, and streaming compilation is what hides most of it behind the download.

We put the longer version together on our own site, WebAssembly for web games, which goes through the toolchains, how each engine handles its web export, and the things wasm still cannot do without JavaScript holding its hand.

Reach for wasm when you have a hot loop running thousands of times per frame, a large existing native codebase, or a workload like physics or a software rasterizer where fixed types and explicit memory genuinely pay. Skip it when the honest answer is that your game logic runs fine in JavaScript. A build step you did not need is a real cost, and the speedup you imagined is often a rounding error.

Fix The Time Step Before You Blame The Physics Engine

Thu, 27 Aug 2026 12:05:16 +0000

A lot of the browser game questions that land on here come down to physics behaving one way on the dev machine and another way on someone else's, and the engine is almost never the reason. This is the version of the explanation I wish someone had given me early, and it applies the same whether you are on Rapier, Cannon-es or Havok.

The Fixed Step Is The Whole Trick

A physics engine advances the world one step at a time. Each step it applies forces, finds contacts, resolves them, and writes new positions and velocities. If you hand it the real elapsed frame time, that step is a different size on every machine, and the numerical integration that turns force into velocity into position produces a different answer each run. Determinism goes, and replays, lockstep multiplayer and reproducible bug reports go with it.

Keep the step fixed, usually at 1/60th of a second, and decouple it from rendering. Accumulate real elapsed time in a buffer, run as many whole physics steps as fit in it, and leave the remainder for the next frame. When the renderer is faster than the physics rate, interpolate between the last two physics states so the motion still looks smooth. A slow frame then runs several small steps to catch up instead of one giant one, which is exactly what stops a fast projectile from tunneling straight through a thin wall.

Body Type Is The Decision People Get Wrong

Every body is dynamic, kinematic or static. Dynamic bodies are moved by forces and pushed by collisions. Kinematic bodies are moved by your code, shove dynamic bodies out of the way and ignore forces entirely. Static bodies never move and cost the least.

Picking wrong is the most common setup mistake I see. A moving platform written as a dynamic body drifts the moment the player lands on it. A player character written as dynamic gets shoved around by every crate it brushes. Most platforms want to be kinematic, most scenery wants to be static, and dynamic belongs to the objects you actually want the simulation to decide for you.

The rest is a handful of properties: mass, moment of inertia, linear and angular velocity, restitution for bounce, friction for grip. Forces apply continuously, like gravity every step. Impulses are instantaneous, like the kick of a jump. Mix those two up and you get a character that either floats or launches into orbit.

Collision Shapes Are Approximations On Purpose

The engine does not use your visual mesh. A 10,000 polygon character is far too expensive to test against every other body every step, so you swap it for a capsule, a box or a convex hull. That is a feature, not a compromise. A sphere against a sphere is one distance comparison. A convex hull pair needs GJK. A triangle mesh is the slowest of the lot, and it belongs on static terrain and almost nowhere else.

What To Reach For

The engines split into pure JavaScript and WebAssembly. Cannon-es is the readable JS option from the pmndrs community, comfortable to roughly 500 to 1,000 active bodies at 60 fps, with use-cannon for React. Rapier is Rust compiled to WASM, SIMD accelerated and several times faster than its 2024 releases, with joints, character controllers and ray casting. Havok's free WebAssembly build ships as the default plugin in Babylon.js 6 and later and is dramatically faster than the old Ammo.js path.

The part that matters more than the ranking is that a physics engine computes positions and rotations and draws nothing at all. Any of them pairs with any renderer, whether that is Three.js, Babylon.js, PixiJS or raw WebGL, and your code is the bridge that copies transforms across once per frame. The full web physics engine comparison covers the 2D options and the older ports too.

The Takeaway

Get the time step right before touching anything else. Fix the step, accumulate the remainder, interpolate for rendering, then choose body types deliberately and keep collision shapes simple. Do those three and the engine you pick becomes a performance decision instead of a correctness one.

Pixlane Media

Wed, 15 Jul 2026 02:42:30 +0000

Hi Coder Legion,

I'm the maker behind Pixlane Media. I started it as a hobby project while teaching myself more C++ and WebAssembly. At first it was just a couple of utilities I personally needed; over time, those small experiments became a broader browser toolkit.

The main design choice is local-first processing. When browser support allows it, images and documents are handled on the device instead of being uploaded to another server. The current collection includes image compression and resizing, background removal, OCR and document scanning, PDF merge/compression, and several on-device AI experiments.

It is currently free to use, with no account required for the tools. I am sharing it as a product I actively maintain, not as a finished answer. I would genuinely value practical feedback from people who build and use web tools:

Does the landing page explain the local-first idea quickly enough?
Which tool feels immediately useful, and which one feels unnecessary?
Is the mobile experience comfortable for real document or image work?
Is there a browser-based media or PDF workflow you would expect but cannot find?
If you notice a slowdown, which browser, device and tool were you using?

You can try it here: pixlane.media

Even a short “this part was clear / this part was confusing” reply would help me decide what to improve next. I am especially interested in feedback about privacy messaging, WebAssembly performance, and the balance between offering many tools and keeping the interface easy to scan.

Thanks for taking a look.

Pytml – Running Python in the Browser Without a Backend

Tue, 30 Jun 2026 17:21:20 +0000

Pytml is a lightweight (~15KB) JavaScript library that acts as a bridge between Python and HTML via WebAssembly. It allows developers to embed and execute Python code directly in HTML pages using a single tag — no server, no complex JavaScript, no setup required.

The library leverages Pyodide (CPython compiled to WebAssembly) to run Python code locally in the user's browser. It automatically handles print() and input() redirection to the DOM, making it perfect for:

Interactive educational tutorials
Classroom coding demos
Rapid prototyping of Python code in web pages

Pytml is open-source (Apache 2.0), listed on OpenForge.gov.in (India's official open-source platform), and has received a Zenodo DOI for academic citation.

Website
Github

How to Build AI Tools That Don't Leak Corporate Data (Using WebAssembly & Next.js)

Fri, 12 Jun 2026 12:30:20 +0000

The AI boom has created a massive problem for B2B startups: Data Leaks.

Every day, startup founders upload unreleased pitch decks, and agencies upload NDA-protected Enterprise RFPs (Request for Proposals) to public AI chatbots to get quick summaries. What they don't realize is that by dragging and dropping a PDF into a standard cloud AI, they are feeding highly confidential intellectual property into remote servers.

As developers, we can do better. We can build AI tools that give users the power of LLMs without compromising the privacy of their source documents.

Recently, I expanded PDF Pro AI—a local-first document workspace—with two new tools: an RFP & Pitch Deck Analyzer and an Insurance Policy Analyzer.

Here is how I architected a 100% private AI extraction pipeline using WebAssembly, React, and Next.js, ensuring the user's PDF never leaves their computer.

The Vulnerability in Standard AI PDF Tools
Most "Chat with PDF" tools follow a dangerous architecture for enterprise data:

User uploads Confidential_RFP.pdf.
The file is saved to an AWS S3 bucket.
A python backend reads the PDF and creates vector embeddings.
The backend sends chunks to OpenAI/Anthropic.
The risk is enormous. The file is sitting in cloud storage. If the database is breached, or the developer misconfigures their S3 bucket, corporate data is leaked.

The Solution: WebAssembly (WASM) Text Extraction
To fix this, we need to extract the text from the PDF before anything touches a network request.

Enter WebAssembly. By compiling Mozilla's pdf.js into Wasm, we can run a high-performance PDF rendering and extraction engine directly inside the user's Chrome or Safari browser.

Instead of uploading a file, the user simply drops the file into a React component. The file is loaded into their local RAM as an ArrayBuffer, parsed by WebAssembly, and the text strings are extracted.

Here is what the local extraction function looks like:

import * as pdfjsLib from 'pdfjs-dist';

// Point to the WebAssembly worker
pdfjsLib.GlobalWorkerOptions.workerSrc = `https://unpkg.com/pdfjs-dist@${pdfjsLib.version}/build/pdf.worker.min.mjs`;

async function extractTextLocally(file) {
  // Load the file into local RAM (No network upload!)
  const arrayBuffer = await file.arrayBuffer();
  
  // Parse the PDF using the local Wasm engine
  const pdf = await pdfjsLib.getDocument({ data: arrayBuffer }).promise;
  let fullText = '';
  
  // Extract text page by page
  for (let i = 1; i <= pdf.numPages; i++) {
    const page = await pdf.getPage(i);
    const textContent = await page.getTextContent();
    const pageText = textContent.items.map(item => item.str).join(' ');
    fullText += pageText + '\n\n';
  }
  
  return fullText;
}

The Secure AI Handoff
Once we have the raw text extracted locally, we can safely send just the text to our Next.js API route via a secure POST request.

The physical .pdf file (which might contain metadata, hidden layers, or signatures) is completely discarded. It never touches our server.

// Inside our Next.js Route Handler (app/api/analyze/route.ts)
export async function POST(req) {
  const { text, documentType } = await req.json();

  // We write a strict system prompt instructing the AI how to behave
  const prompt = `
    You are a highly critical Venture Capitalist evaluating a startup pitch deck.
    Analyze the following text and return a JSON object containing the "readinessScore",
    "valueProposition", and any critical "redFlags".
    
    Text: ${text.substring(0, 15000)}
  `;

  // Send the prompt to the LLM (Gemini / OpenAI)
  const response = await fetch("https://api.llm-provider.com/generate", {
    method: 'POST',
    body: JSON.stringify({ prompt })
  });

  const data = await response.json();
  return NextResponse.json(data);
}

Why This Architecture Wins B2B Users
By separating the extraction layer (Local WebAssembly) from the analysis layer (Cloud LLM API), we achieved a massive security upgrade.

When an agency uses our RFP & Pitch Deck Analyzer, they know their NDA-protected RFP isn't being saved to a random database.

When a user runs their Health Insurance policy through our Insurance Policy Analyzer to find hidden exclusions, they know their medical history isn't being retained for training data.

As developers, it's our responsibility to protect our users' data. Stop uploading files to the cloud when the browser is already powerful enough to do the heavy lifting locally.

Rahul Banerjee is the creator of PDF Pro, a privacy-first suite of over 20+ PDF utilities and AI Document Analyzers powered by WebAssembly.

Why I Made Privacy the Core Feature of PDF Pro — and What Happened to Signups.

Mon, 01 Jun 2026 13:54:19 +0000

When I first launched PDF Pro AI, I had a hypothesis: people are tired of uploading their sensitive data to random cloud servers just to perform basic file operations.

We live in an era where data breaches are daily news, yet developers still casually rely on external API endpoints for simple tasks like file compression or document merging. Think about how many times a user uploads a highly confidential bank statement, a signed NDA, or an employment contract to a random "Free PDF Tools" website.

Where does that data go? Who is looking at it? When is it actually deleted?

As a developer, I realized that if I wanted to build a tool people actually trusted, I needed to eliminate the server entirely. Here is why prioritizing privacy through "Edge Computing" and client-side processing isn't just an ethical choice—it is a massive competitive advantage.

The Problem with the "Upload to Process" Model
For the last decade, the standard architecture for SaaS tools has been:

User uploads a file via an HTML form.
The server receives it, temporarily stores it in an S3 bucket, and triggers a background job.
A heavy Python or Node.js process does the manipulation.
The server returns a download link to the user.
This architecture is fundamentally flawed for two reasons:

It's expensive: You have to pay for the ingress bandwidth, the compute time for the background job, and the storage buckets.
It's a privacy nightmare: You are legally responsible for safeguarding the user's data while it sits on your server.

The Solution: Shifting Compute to the Browser
When architecting the core engine for PDF Pro AI, I made a strict rule: Zero Cloud Uploads.

Instead of relying on a backend server, I utilized WebAssembly (WASM). By compiling heavy C++ and Rust libraries down to WASM, modern web browsers can now execute incredibly complex operations natively, using the end-user's own hardware.

When a user visits PDF Pro to extract pages from a document or compress a massive 50MB presentation, the entire operation happens entirely inside their laptop's RAM.

This creates a win-win scenario:

The User wins: Their documents never leave their device. They don't have to trust me to delete their files, because I never received them in the first place. Their privacy is mathematically guaranteed by the architecture.

I win: Because the user is providing the compute power, my AWS server costs are essentially zero. The tool scales infinitely without requiring me to provision more backend instances.
The Takeaway for Developers
We are rapidly moving toward a future where "serverless" doesn't just mean AWS Lambda—it means literally pushing the workload entirely to the client's browser.

If you are building tools that manipulate documents, images, audio, or video, I strongly urge you to investigate WASM libraries (like pdf-lib, ffmpeg.wasm, or sharp client-side ports).

Build products that respect your users' data by default. Make privacy the foundation of your architecture, rather than an afterthought.

Rahul Banerjee is a software engineer and the creator of PDF Pro AI, a privacy-first document workspace featuring 100% local PDF manipulation tools and secure AI contract analysis.

How I Built a 100% Local, Zero-Upload PDF Editor Using WebAssembly

Sat, 30 May 2026 13:22:14 +0000

I used to hate dealing with PDFs.

Every time I needed to merge two pages of a bank statement or compress an identity document for a government portal, my only option was to Google "free PDF compressor" and upload my sensitive files to a random server halfway across the world.

As a developer, that felt completely wrong. Why do my files need to leave my machine just to get compressed or merged?

I decided to solve my own problem and build PDF Pro AI—a 100% private, zero-upload document workspace. The rule was simple: all processing had to happen locally in the user's browser.

Here is exactly how I architected a serverless PDF editor using WebAssembly, React, and Next.js, and why you should consider moving heavy computation to the client side.

The Problem with Cloud PDF Tools
Most free PDF tools use a standard architecture:

You upload your file.
The server spins up a heavy Python or Node.js process using libraries like PyPDF2 or Ghostscript.
It does the manipulation.
You download the result.
The server (hopefully) deletes your file.
This is slow, expensive to scale, and fundamentally a massive privacy risk. If a user is uploading a highly confidential NDA or a bank statement, they have to trust that your cron job actually deletes the file.

I wanted to eliminate the server entirely.

Enter WebAssembly (WASM) and pdf-lib
To do heavy document manipulation without a backend server, I turned to WebAssembly.

Specifically, I built the core engine around pdf-lib, a fantastic JavaScript library that works beautifully in modern browsers. Instead of relying on a server to crunch the bytes, pdf-lib leverages the user's own CPU to modify the PDF structure locally.

Here is what the architecture looks like for merging two PDFs directly in the browser:

import { PDFDocument } from 'pdf-lib';

async function mergePDFsLocally(files) {
  // Create a brand new, empty PDF document
  const mergedPdf = await PDFDocument.create();

  for (const file of files) {
    // Read the user's file as an ArrayBuffer directly from the file input
    const arrayBuffer = await file.arrayBuffer();
    
    // Load it into pdf-lib
    const pdf = await PDFDocument.load(arrayBuffer);
    
    // Copy all pages from the source PDF
    const copiedPages = await mergedPdf.copyPages(pdf, pdf.getPageIndices());
    
    // Append them to our new document
    copiedPages.forEach((page) => mergedPdf.addPage(page));
  }

  // Serialize the final document to bytes
  const mergedPdfBytes = await mergedPdf.save();
  
  // Create a local blob URL for the user to download instantly
  const blob = new Blob([mergedPdfBytes], { type: 'application/pdf' });
  return URL.createObjectURL(blob);
}

The Magic of the Blob URL
Look closely at the last three lines of that code snippet. That is where the magic happens.

When the PDF is finished merging, I convert the raw bytes into a Blob and generate an Object URL using URL.createObjectURL().

This creates a temporary, local-only download link that looks something like blob:https://www.pdfpro.co.in/5b8f.... The file never touched an S3 bucket. It never hit an API endpoint. The entire operation happened in the RAM of the user's laptop.

The result? The merge happens in less than 50 milliseconds, and the user's privacy is mathematically guaranteed because the file literally cannot leak.

Handling Compression with PDF.js
Merging is relatively straightforward, but what about compressing?

Compressing a PDF locally is notoriously difficult because you essentially have to re-render the document and strip out unoptimized metadata. For this, I combined pdf-lib with Mozilla's pdf.js worker.

The workflow I built does the following:

pdf.js reads the document and extracts the raw text and image assets on a background web worker thread (so the UI doesn't freeze).
I compress the extracted images locally using HTML5 rendering.
pdf-lib reconstructs the PDF using the newly compressed assets.
It took a lot of trial and error to get the memory management right—large PDFs can easily crash a browser tab if you don't aggressively clear your ArrayBuffers for garbage collection—but the final product is incredibly fast.

Why This Matters for Indie Hackers
Moving heavy workloads to the browser isn't just about privacy; it is an incredible cost-saving hack for solo founders.

Because PDF Pro doesn't rely on expensive cloud functions or heavy backend storage buckets for standard document editing, my AWS/Vercel bill for that specific feature is exactly $0.00. The users provide their own compute power. I just provide the WebAssembly instructions.

If you are building a tool that manipulates images, audio, video, or documents, I highly recommend exploring WebAssembly and client-side processing before reaching for a server. Your users will love the privacy, and you will love the hosting bill.

Rahul Banerjee is a software engineer and the creator of PDF Pro AI, a privacy-first document workspace featuring local PDF tools and AI-powered contract analysis.