MuPDF.js

What it does

Artifex's official JavaScript and TypeScript binding to the MuPDF C engine, compiled to WebAssembly so the same code runs in browsers and in Node, Bun or Deno. It renders pages to PNG, JPEG or an HTML5 canvas, extracts plain or structured text with positions, searches text, creates and edits annotations including permanent redaction, merges and rearranges pages, reads and writes form field values and metadata, and can save with encryption options.

Best for: Teams that need high-fidelity rendering plus genuine editing — redaction, annotation, merging, encryption — in one client-side or server-side JavaScript stack, and that can either comply with the AGPL or buy a commercial licence.

Worth knowing: Licensing is the real decision: the engine is AGPL-3.0 or a commercial licence from Artifex, and the vendor’s distinction is that a commercial licence is required where AGPL compliance is not possible, which is a statement about the licence rather than legal advice for a particular product. The official npm package is `mupdf`; the older, similarly named community `mupdf-js` package is deprecated, so which package a project depends on matters. The examples cover both browser processing and a Node REST server, so this is a browser and Node deployment rather than a no-server one, and running the engine locally says nothing about what the application hosting it uploads or stores. The WebAssembly binary adds to a client bundle; the previously recorded 8 to 12 MB figure was an estimate without a version or a measurement, so transfer size and unpacked size would need measuring before either is published.

Details, and where each comes from

Vendor statements, our own reading of their pages, and the things nobody has established yet, each answered separately. Where we have not confirmed something it says so rather than guessing, and a row nobody has established is greyed out.

Versions covered

Web · Self-hosted

Website

mupdfjs.readthedocs.io

Requires an account

Not applicable

Watermark on the free tier

Not verified

Maximum file size

Not verified

Batch processing

Yes

Data residency

Self-hosted

Open source

Yes

Self-hostable

Yes

Licence

AGPL-3.0, dual-licensed with a commercial licence from Artifex

Redaction

Removes the content

Programmatic access

Embeddable library · Browser JavaScript

Last availability check

Responded in 247 ms 16 October 2026

Checked automatically by our own runner, not reported by the vendor. 100% of our last 30 checks got a response.

What the vendor says

Claims are labelled rather than repeated as fact. Where we have checked something ourselves, it says so and shows when. Checked means we read the vendor's own page and it says what we recorded — not that we tested the behaviour, unless the note says we did.

• “MuPDF.js is the official JavaScript and TypeScript library for reading, rendering, and manipulating PDF documents.”

  Checked by us — the source says this Read 22 September 2026

  Confirmed verbatim: the sentence is the README's opening line, and it continues with the detail that matters technically — "It wraps the MuPDF C engine in WebAssembly, so the same high-fidelity rendering runs in Node.js, browsers, Bun, and Deno — with no native dependencies." The word "official" is doing real work here: MuPDF.js is published by Artifex, the maker of MuPDF, which distinguishes it from a third-party wrapper, and it is the same vendor whose AGPL terms are recorded in the licensing tier. So the licensing claim and this capability claim describe the same product from the same source, and a reader weighing the AGPL obligation should read them together.

  Standing: Re-read and matched byte for byte

  Check it yourself: the source, the SHA-256, and how we checked

  Read

  https://github.com/ArtifexSoftware/mupdf.js

  From

  the text a browser renders

  SHA-256

  eb594a116224d246ef6f9b9901f599ab04866dfddd4c24a9fab65371a518d64c

  How we checked: Re-verified verbatim on 2026-09-22: https://github.com/ArtifexSoftware/mupdf.js re-rendered in headless Chrome with scripts/render-page.mjs and the claim's wording found in the rendered text. Originally verified on 2026-09-21. sourceHash is the SHA-256 of the re-rendered text, held as rv-github-com-ArtifexSoftware-mupdf-js-eb5fba1b.txt.

  What this hash proves, and what it does not

• “AGPL v3: Free for open-source projects. If you distribute software using MuPDF.js or provide it as a network service, you must release your source code under AGPL.”

  Checked by us — the source says this Read 21 September 2026

  Confirmed verbatim: under a question reading "What license is MuPDF.js under?", the answer states "AGPL v3: Free for open-source projects. If you distribute software using MuPDF.js or provide it as a network service, you must release your source code under AGPL." The same answer gives the commercial alternative for "proprietary applications, SaaS products, or when you can't comply with AGPL" and adds a scope note the claim omits: "The licensing applies to both the JavaScript wrapper and the underlying MuPDF WASM binary." That matters because it means the AGPL obligation cannot be avoided by treating the WASM binary as a separate component. This is the same Artifex licensing model recorded for MuPDF itself, Ghostscript and PyMuPDF in this batch.

  Standing: Re-read and matched byte for byte

  Check it yourself: the source, the SHA-256, and how we checked

  Read

  https://mupdfjs.readthedocs.io/en/latest/faq/

  From

  the raw HTTP response

  SHA-256

  ed59297cff945d6f9b1885daaf6c081ddfeb1b832a45904d5b009100f38cc1b6

  How we checked: The recorded source is the MuPDF.js FAQ; the URL implied by it (faq.html) returns 404, and the live page is https://mupdfjs.readthedocs.io/en/latest/faq/. Its rendered text is 1995 bytes and does not contain the licensing section at all, so the claim was read from the raw HTML response, 50234 bytes saved and hashed, where the answer sits in a collapsed FAQ block. sourceHash is the SHA-256 of that raw response.

  What this hash proves, and what it does not

• “Genuine redaction: a Redact annotation plus page.applyRedactions() permanently removes the marked content, and the original cannot be recovered.”

  Checked by us — the source says this Read 17 September 2026

  The boxed string is gone from the saved file, and the lines 40pt above and below it survived, as did an entirely untouched second page. The output contains zero image XObjects, so nothing was rasterised: the marked text is deleted from the page structure and a solid fill is drawn where it was. qpdf reports no errors and agrees on every marker. This is removal, not covering — the first of the three verdicts in the index to be confirmed by test rather than by vendor documentation, and the one where the vendor was telling the truth.

  Standing: Re-read and matched byte for byte

  Check it yourself: the source, the SHA-256, and how we checked

  Read

  https://github.com/ArtifexSoftware/mupdf.js

  From

  the text a browser renders

  SHA-256

  8d6ce98159ba113288b2f3c15cde6ffd20f5359718eea9ffc5a81402f7fdf102

  How we checked: The MuPDF engine driven directly through mupdf.js 1.28.1 on a two-page canary PDF. The redaction rectangle was derived from the engine's own text extraction rather than hard-coded, so the box provably covered the target. The saved output was normalised with qpdf, the reference implementation, and searched for every marker; a control ran the identical search against the unredacted original, where all markers are present. Its source page was re-read on 2026-09-21 to record the source hash the original reading did not carry; the wording quoted in the claim is unchanged, so this does not re-date the verification, and sourceHash is of that re-read.

  What this hash proves, and what it does not

Each claim is quoted from the vendor's own pages. This section describes what we have and have not checked — it is not a judgement about anyone.