DEV Community: El_Necora

What you can (and cannot) do to a PDF entirely in the browser

El_Necora — Thu, 06 Aug 2026 11:06:15 +0000

Every "free PDF tool" site works the same way: you upload your file, a server does the work, you download the result. Which is fine for a restaurant menu and considerably less fine for a signed contract, a payslip, or a scan of your passport.

A friend and I wanted to know how much of that could just happen locally. Turns out: most of it. But the boundary is in a place I didn't expect, and a couple of the "obvious" implementations are quietly wrong in ways that matter.

Here's the map, based on building about 27 of these.

The easy tier: structural edits

Merging, splitting, rotating, reordering pages, adding page numbers — none of this needs you to render anything. A PDF is a document object model. pdf-lib lets you open it, move objects around, and write it back out.

const merged = await PDFDocument.create();
for (const bytes of files) {
  const src = await PDFDocument.load(bytes);
  const pages = await merged.copyPages(src, src.getPageIndices());
  pages.forEach(p => merged.addPage(p));
}
const out = await merged.save();

That's the whole merge tool. It runs in milliseconds and there is genuinely no reason for this to ever touch a server. The fact that it usually does is a business decision, not a technical one.

The middle tier: you need pixels

Converting to JPG, compressing, extracting images — now you need pdf.js to actually rasterize pages onto a canvas. Slower, heavier, but still entirely local.

The trap: redaction

This one deserves its own section because getting it wrong is a real problem, and plenty of tools do get it wrong.

The intuitive implementation of "redact this paragraph" is: draw a black rectangle over it. It looks perfect. The PDF opens with a black bar exactly where the sensitive text was.

The text is still there.

PDFs keep content in layers. A rectangle drawn on top is a new object; the text object underneath is untouched. Select-all and copy, or run any text extractor, and the "redacted" content comes straight out. This has burned actual law firms and government agencies — there's a genuine history of court filings being un-redacted by journalists with Ctrl+A.

Doing it properly means destroying the information, not covering it:

Render the page to a canvas with pdf.js
Fill the redaction rectangles black on the canvas
Build a new PDF from the resulting raster image

You lose the text layer for that page — the output is a picture of a document rather than a document. That is not a side effect to apologise for, it's the entire point. If the text is still selectable, you didn't redact anything.

The gotcha: pdf-lib can't encrypt

I wanted a "password protect this PDF" tool. pdf-lib doesn't do encryption. Not a flag I missed — it isn't implemented.

@cantoo/pdf-lib is a fork that adds it, with the same API:

await doc.encrypt({ userPassword: pw, ownerPassword: pw });

The reverse direction is more interesting. PDFs have two kinds of password:

Owner password — restrictions on printing, copying, editing. This is a flag the viewer is politely asked to respect. Load with ignoreEncryption: true, save again, restrictions gone. It was never security.
User password — actual encryption. The file content is genuinely encrypted and without the password there is nothing to recover.

So the unlock tool removes the first and cannot touch the second, and the FAQ says exactly that. I'd rather explain the limit than have someone assume we're a cracking service.

"Editing" a PDF, honestly

The flagship tool is editing, and I want to be precise about what it does, because most tools in this space are vague on purpose.

You are not editing the original text stream. Reflowing text inside an existing PDF means reconstructing font metrics, kerning and line breaking for embedded subsets — that's a research project, not a weekend feature.

What you can do, and what actually solves the problem people have, is overlay: white-out box over the old text, new text on top, plus drawing, images and signatures. Export flattens it all with pdf-lib. From the user's side it reads as editing. It also works on scans, where there is no text layer at all.

The one thing that will eat an afternoon is coordinates. The browser puts the origin top-left, PDF points put it bottom-left, and your canvas is at some display scale that isn't 1:1:

const pdfX = cssX / scale;
const pdfY = pageHeight - (cssY / scale) - elementHeight;

Get that wrong and everything lands mirrored down the page, which is a genuinely funny bug the first time.

OCR, and being consistent about it

For scanned documents you need OCR, and tesseract.js is excellent. By default it fetches its worker, its WASM core and the language data — about 24MB — from a CDN at runtime.

Which would have meant a site whose entire premise is "your files never leave your browser" reaching out to a third party the moment you use it. Not the same thing as uploading your file, but not a distinction I wanted to have to explain either.

So it's all self-hosted:

const worker = await createWorker(lang, OEM.LSTM_ONLY, {
  corePath: '/tesseract/',
  langPath: '/tesseract/lang'
});

Bigger deploy, zero external calls. If you're making a privacy claim, it should survive someone opening the network tab.

What genuinely doesn't work well

PDF to Word. You can pull the text out with pdf.js and group it into lines by Y coordinate, and we ship that — but layout reconstruction, tables and styling are not happening client-side at any quality worth defending. The tool says so up front rather than producing a mess and letting you find out.

PowerPoint we skipped entirely. Bad effort-to-value ratio.

Where it landed

27 tools, all client-side, free, no watermark, no sign-up, no upload. Built with Astro, deployed as a static site. English and Spanish.

https://docuniversal.com

The stack is basically pdf-lib / @cantoo/pdf-lib for structure, pdf.js for rendering, tesseract.js for OCR, mammoth and docx for Word, SheetJS for spreadsheets. All of it has been sitting in npm for years. Nobody needed to build the upload-a-server version of this in the first place.

If you're doing something similar and hit a case where the browser genuinely can't cut it, I'd like to hear which one.

Compiling libjxl to WASM so browsers can open JPEG XL files

El_Necora — Thu, 06 Aug 2026 10:46:12 +0000

Chrome shipped JPEG XL behind a flag in 2021, then pulled it in 2022. Firefox has it in Nightly only. Safari supports it. So depending on which browser you happen to have open, a .jxl file is either an image or a file your OS shrugs at.

That's an annoying place for a format to be, because people do end up with these files. Some camera and phone export pipelines produce them, and anyone who has gone down the "let me re-encode my photo library" road has a folder of them somewhere. Then they try to open one on a machine that isn't a Mac and nothing happens.

I wanted a viewer that runs entirely in the browser — no upload, no server touching the file. That part is non-negotiable for me; if you're going to look at your own photos you shouldn't have to POST them to a stranger first. Which means the decoder has to be WASM.

Here's what that actually took, including the part where it broke in production.

Starting with jSquash

@jsquash/jxl is the obvious starting point. It's a nicely packaged WASM build of libjxl and it works. I shipped with it.

Then someone on Reddit tried a 22.4 megapixel file and got:

RuntimeError: index out of bounds
    at toWireType

Not a great error message. The encoder was dying somewhere between 12 and 16 megapixels — under that, fine; over it, dead. The heap can grow to 2GB but it never gets close before falling over, so it's not a simple "raise the limit" fix.

And even below the limit it was slow. A 12MP image took 21 seconds at effort 7. Nobody waits 21 seconds.

So: build libjxl myself.

The build

Standard emscripten setup:

git clone --depth 1 https://github.com/emscripten-core/emsdk.git
cd emsdk && ./emsdk install latest && ./emsdk activate latest
git clone --depth 1 --recurse-submodules --shallow-submodules https://github.com/libjxl/libjxl.git

The cmake invocation is where the interesting decisions live:

source ~/emsdk/emsdk_env.sh && cd ~/libjxl
emcmake cmake -B build-wasm -S . -DCMAKE_BUILD_TYPE=Release \
  -DBUILD_SHARED_LIBS=OFF \
  -DJPEGXL_ENABLE_WASM_THREADS=OFF \
  -DBUILD_TESTING=OFF -DJPEGXL_ENABLE_BENCHMARK=OFF -DJPEGXL_ENABLE_EXAMPLES=OFF \
  -DJPEGXL_ENABLE_MANPAGES=OFF -DJPEGXL_ENABLE_JNI=OFF -DJPEGXL_ENABLE_PLUGINS=OFF \
  -DJPEGXL_ENABLE_VIEWERS=OFF -DJPEGXL_ENABLE_DOXYGEN=OFF -DJPEGXL_ENABLE_TOOLS=ON \
  "-DCMAKE_EXE_LINKER_FLAGS=-sEXPORTED_RUNTIME_METHODS=FS,callMain -sFORCE_FILESYSTEM=1 -sALLOW_MEMORY_GROWTH=1 -sINVOKE_RUN=0 -sEXIT_RUNTIME=0 -sMODULARIZE=1 -sEXPORT_NAME=createCjxl"

emmake make -C build-wasm cjxl -j6

Two of those flags are load-bearing and the rest is just trimming fat.

-DBUILD_SHARED_LIBS=OFF — without it the link fails looking for libjxl_cms.so. Shared libraries in a WASM build don't mean what you want them to mean.

-DJPEGXL_ENABLE_WASM_THREADS=OFF — this one is a real architectural choice, not a workaround. Turning threads on pulls in pthreads, which needs SharedArrayBuffer, which needs you to serve the page with Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy headers. Those headers put your document in a different agent cluster and quietly break most third-party embeds. If your page is nothing but the tool, go for it. If it has anything else on it, you're choosing between threads and the rest of your page working.

I chose single-threaded. Which leads directly to the next thing.

The effort cliff

libjxl's -e flag goes from 1 to 9. Higher effort, smaller file, more CPU. Conventional wisdom says 7 is a good default.

Single-threaded in WASM, on a 22.4MP image:

effort	time
4	~3s
5	~25s
7	~49s

That's not a curve, that's a wall between 4 and 5. Eight times slower for a file size difference most people would not notice. I have not dug into which specific passes turn on at effort 5, and I'd genuinely like to know, but empirically -e 4 is the only setting that makes browser-side encoding of large images feel like software rather than a punishment.

For comparison, small images through this path come out roughly 10x faster than jSquash at effort 7. The fix for the crash turned out to also be the fix for the speed.

Feeding it pixels

Here's a trap I walked straight into. I stripped the build down, which means there is no JPEG decoder inside it. So this:

cjxl in.jpg out.jxl --lossless_jpeg=0

fails with Getting pixel data failed. It can't read the JPEG.

The fix is to let the browser do what browsers are already extremely good at — decode the image to a canvas — and hand cjxl raw pixels as a netpbm file. PPM for RGB, PAM when there's an alpha channel:

// no alpha
const header = `P6\n${w} ${h}\n255\n`;   // + RGB bytes

// with alpha
const header = `P7\nWIDTH ${w}\nHEIGHT ${h}\nDEPTH 4\nMAXVAL 255\nTUPLTYPE RGB_ALPHA\nENDHDR\n`;  // + RGBA bytes

Then:

await loadScript("/assets/vendor/jxl-enc/cjxl.js");
const m = await createCjxl({
  noInitialRun: true,
  locateFile: p => "/assets/vendor/jxl-enc/" + p
});
m.FS.writeFile("in.ppm", ppmBytes);
m.callMain(["in.ppm", "out.jxl", "--num_threads", "0", "-q", "90", "-e", "4"]);
const jxl = m.FS.readFile("out.jxl");

--num_threads 0 is not optional. A build made without thread support aborts if you don't pass it explicitly.

Also: instantiate a fresh module per file. Once an emscripten module aborts, it stays dead — the cached instance will keep failing until you reload the page, and you will spend an hour convinced your input is malformed.

The path that was fine all along

None of the above applies to lossless JPEG transcoding, which is the genuinely great trick JPEG XL has and which almost nobody knows about.

JxlEncoderAddJPEGFrame doesn't decode your JPEG and re-encode it. It repacks the existing coefficients with better entropy coding. You get a file 10-20% smaller, and decoding it reconstructs the original JPEG bit for bit. Not "visually identical" — the same bytes.

m.callMain(["in.jpg", "out.jxl", "--num_threads", "0", "--lossless_jpeg=1"]);

I verified it the boring way: transcode with cjxl, reconstruct with djxl, compare sha256 of original and reconstruction. Identical.

That path never had the memory problem, because it never touches pixels. 22.4MP goes through in about 0.6 seconds.

If you have a photo archive sitting in JPEG, this is close to free space. Nothing is lost and it's reversible.

Where it ended up

Everything runs client-side. Files never leave the browser, which for a tool people point at their own photos seemed like the only defensible design.

The viewer is here if it's useful to you: https://jpegxlconvert.com/en/jxl-viewer/

Drop a .jxl in, it renders. It'll also convert to PNG or JPG if you need something the rest of your OS understands.

If you know why effort 5 falls off that cliff, I'd like to hear it.

I built a private, 100% in-browser JPEG XL converter (no upload, no server)

El_Necora — Thu, 25 Jun 2026 10:22:14 +0000

If you've ever downloaded a .jxl file and watched your browser shrug at it, you've met the JPEG XL problem: it's a genuinely great image format that almost nothing opens yet. So I built a small tool that converts images to and from JPEG XL entirely in the browser — no upload, no account, no server touching your files.

Live: https://jpegxlconvert.com · Source: https://github.com/robertcassch-dot/jpegxlconvert

Why bother?

JPEG XL (.jxl) gives you smaller files at the same quality, lossless JPEG repacking (~20% off your existing JPEGs with zero quality loss), transparency, and a royalty-free spec. The catch in 2026 is support: most browsers and apps still can't display a .jxl. Chrome removed it in 2022 and is in the process of bringing it back — but until that's everywhere, people keep ending up with .jxl files they can't view.

Most "online converters" answer that by uploading your image to their server. For a personal photo, that's a lot of trust for a format conversion. I wanted the opposite: the file never leaves your device.

How it works

Everything runs client-side with WebAssembly:

JPG / PNG / WebP / GIF → JXL: the browser decodes the source natively, then @jsquash/jxl (libjxl compiled to WASM) encodes the JXL.
.jxl → PNG / JPG: decoded with @jsquash/jxl, re-encoded natively via a <canvas>.
HEIC (iPhone photos) → JPG/PNG/JXL: decoded in-browser too, so you can finally open HEIC outside Apple's world.

import { encode } from '@jsquash/jxl';

const bitmap = await createImageBitmap(file);          // native decode
const canvas = new OffscreenCanvas(bitmap.width, bitmap.height);
canvas.getContext('2d').drawImage(bitmap, 0, 0);
const imageData = canvas.getContext('2d')
  .getImageData(0, 0, bitmap.width, bitmap.height);

const jxl = await encode(imageData, { quality: 90 });  // WASM encode, on-device

No fetch() to a backend anywhere in that path — you can verify it in the Network tab, which is kind of the whole point.

A few things I learned

Self-host the WASM codec. Pulling it from a CDN at runtime works in dev, but for speed, reliability and a cleaner privacy story you really want the .wasm served from your own origin.
Orientation metadata bites you on HEIC. iPhone photos lean on EXIF orientation; if you ignore it, half your conversions come out sideways.
A "viewer" is half the product. Plenty of people don't want to convert — they just want to see the .jxl. Decoding it to a <canvas> and offering a one-click "save as JPG/PNG" turned out to be the most-used path.

It's open source

The whole static site is on GitHub: https://github.com/robertcassch-dot/jpegxlconvert. It's multilingual (EN/ES/DE/FR/RU), deploys to any static host (I use Cloudflare Pages), and has zero backend.

If you've got .jxl files gathering dust, try it: https://jpegxlconvert.com. Feedback and issues welcome.