Loading today’s stories
Build1 distinct publisher3 min readPublished
The PDF tools run pdf.js, pdf-lib, qpdf and Tesseract as lazily loaded WASM inside the tab, and one CSP directive turns the privacy claim into something you can check in the Network panel instead of read in a policy.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
FFmpeg.wasm ships, but budget for a watchdog: one in ten heavy jobs deadlocked in silence1 distinct publisher
build
pdf-lib's ignoreEncryption flag does not skip encryption, it hands you a broken PDF1 distinct publisher
build
A strict CSP killed one form in production, and every monitor stayed green1 distinct publisher
build
A Green Link Report Says Nothing About Whether Your HTTPS Page Renders1 distinct publisher
"self" is the word to read twice. The header pins connections to the page's own origin [11], and a site with a working upload endpoint could ship exactly that policy and still take your payslip. The guarantee only becomes structural in combination: nothing is listening on the origin [1], so "self" resolves to nowhere [3]. Drop the static-site half and you are back to a promise about timing [13].
Four runtimes have to come off that origin. pdf.js renders pages to canvas and extracts text and structure [3]. pdf-lib edits document structure for merges, splits, metadata and form filling [4]. tesseract.js runs OCR with its worker, core and language models [5]. qpdf does encryption, decryption and repair [8]. Four, counting qpdf, which the post lists apart from its three engines [1]. Each loads lazily, so someone opening the rotate-pages tool never downloads the OCR core [2]. Serving all of it yourself is the hosting cost the CDN default hides [4].
qpdf gets a fresh instance for every operation, because the Emscripten runtime cannot be reused after callMain [9]. The .wasm binary stays in the browser's HTTP cache [10], so the repeating cost is instantiation rather than transfer [2]. The OCR options are worth reading past the paths, too: gzip is true and cacheMethod is "none" [6]. The post does not say what disabling that cache costs on the second OCR run in a session, and it is the first number I would go measure.
Two things have to be true of your workload before this pattern transfers. Every operation you need has to be expressible in those four engines. And you have to be able to run with no third-party connection at all, because crash reporting, product analytics, remote config and server-side licence checks are all connections, and the policy refuses them [11]. The privacy property is paid for in observability.
The redaction tradeoff is the one I would argue about at review. A black box drawn in a viewer leaves the text selectable underneath [14], which is why the tool repaints pixels and rebuilds the file from images instead [15]. The output loses its whole text layer, not only the redacted words [16], so search, accessibility and copy-paste go with it. The same tab ships an OCR engine [5], so you can rebuild a text layer from the image you just made, which is a fairly funny lap to run.
The next section of the post opens on PDF/A, the ISO standard for long-term archival [17], and the copy available to us stops mid-sentence [18]. What is testable today is the claim that matters for a signed contract: open the Network panel, run the operation, count the requests [12].
Ranked by verification strength, evidence, and original report placement.
Vellum is a static site with no backend, no API and nothing listening for a file; everything that used to be send-to-server, run-a-tool, send-back happens as WebAssembly and JavaScript in the browser tab.
Three engines carry the actual PDF work, each loaded lazily so a user opening the rotate pages tool does not pay for OCR they will never touch.
pdf.js (pdfjs-dist) renders pages to canvas and extracts text and structure; it is Mozilla's PDF engine, already shipped in every Firefox and Chrome tab, loaded by the site itself rather than relying on the browser's built-in viewer.
pdf-lib manipulates PDF structure directly: merging, splitting, page operations, metadata and form filling.
Tesseract, compiled to WebAssembly via tesseract.js, does OCR; the worker, the WASM core and every language model are self-hosted under /tesseract/ with nothing fetched from a CDN.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 1, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Self-reported, but unusually checkable
Every detail this story turns on comes from the people who wrote the code, published on dev.to, and no third party has looked. What lifts it above an ordinary vendor post is the kind of proof offered: excerpts quoted straight out of src/lib/ocr.ts, src/lib/qpdf.ts and src/lib/redact.ts, a named ISO validator wired into the build, and a response header any reader can pull up for themselves. Saying a thing and showing a mechanism are different acts, and both are present here — in a text that stops before the write-up finishes.
No usage of any kind reported
Not one number about people. No installs, no visitor counts, no download figures, no named organisation processing documents this way, no release or version history. We know how the tools are built and nothing whatsoever about whether they are used, and inventing a figure from a build log would be worse than leaving this blank.
One header carrying a slightly larger promise
The phrase doing the most work is 'structurally impossible', and the mechanism quoted supports a narrower statement: connect-src 'self' shuts out third-party origins, not the site's own. The no-upload property therefore leans on the separate claim that there is no backend at all — plausible for a static site, unverified by anyone outside. Set against that overreach, the post talks its own product down in places most marketing would not: redacted files lose selectable text, the faithful PDF/A mode cannot guarantee conformance, and big scans will exhaust the tab.
The builders marketing their own build
'We build Vellum' appears in the second paragraph, and the piece is a developer-platform post promoting a free product by contrasting it with every competitor's upload button. That is a strong reason to present the architecture at its best. It also explains the shape of the writing: the engineering detail is specific enough to be checked, which is exactly what a builder shows when the pitch is trustworthiness — and the numbers a skeptic would want, usage and cost, are the ones not offered.
Confident about the code, blind about the world
We can say with reasonable assurance what this software is designed to do, because the design is quoted. We can say almost nothing about how the deployed site behaves under scrutiny, who uses it, or what the closing paragraphs said — one interested source, no external check, and a truncated text.